1. Design and Implementation of a Secure UPnP Environment
Distributed Computing and Network Security Lab
National Taiwan University
Last Update:
<Project Members> Chun-Ying Huang, Jiunn-Jye Lee, Chia-Chang Hsu, Ssu-Ying Lee, Che-Jui Hsu, Chou-Chin Kang, Chia-Wei Hsu
2019/2/25
SUPnP -

2. Outline System Architecture UPnP Introduction Project Goal
Protocol Design
Implementation
Other Related Services
2019/2/25
SUPnP -

3. System Architecture
2019/2/25
SUPnP -

4. UPnP Introduction UPnP – Universal Plug-and-Play The Problem
A controller maintains all network devices.
Connect network devices seamlessly.
Zero-configuration
The Problem
No secure data transmission protocol for the UPnP environment.
2019/2/25
SUPnP -

5. Project Goal Construct a secure UPnP environment Node authentication
Secure data communication: for both unicast and multicast (group) communications
Allow both encrypted and unencrypted messages in the network
Compatible with the original insecure UPnP architecture
2019/2/25
SUPnP -

6. Protocol Design Design Philosophy Assumptions Programming Interfaces
Node Registration
Data Communication
Re-Key
Network Expansion
Prerequisite
2019/2/25
SUPnP -

7. Design Philosophy Layered design: Increase compatibilities 2019/2/25
SUPnP -

8. Assumptions Each application can be assigned some predefined “secrets”
e.g. username, password, and/or secret keys
Key server can be fully trusted
However, it should …
Prevent password leakage even it is compromised.
2019/2/25
SUPnP -

9. Programming Interfaces
For client APP
supnp_client_init()
supnp_login(user-ID, password)
supnp_client_send(data, length, callback-func)
DEF: callback-func(data, length)
For server APP
supnp_server_init()
supnp_server_setcallback(callback-func)
DEF: callback-func(msg-ID, data, length)
supnp_server_send(msg-ID, data, length)
EXTRA (for the key server and forwarder support) - supnp_keyserver_setcallback(callback-func)
DEF: callback-func(msg-ID, length, supnp-control-message)
More SUPnP APIs
supnp_mode_insecure() supnp_mode_secure()
2019/2/25
SUPnP -

10. Protocols should be encapsulated in command packets
Node Registration
Client knowledge
Identity and password
Key server knowledge
SALT, H(SALT, PWD), user-type (is a client or a server) of each identity
Request identifier
A request is identified by the sequence number and the ID (generated by client)
The “KeyRing”
For server nodes:
A sequence of LKH (ID, Key) pairs
For client nodes (readers):
A session key
Protocols should be encapsulated in command packets
2019/2/25
SUPnP -

11. Node Registration (Cont’d)
“KeyRing” Format
Fields:
(ID/algorithm/N-key are in 32-bit big-endian byte order)
ID: the key ID of the client (receiver)
algorithm: the encryption algorithm
N-key: the number of keys in the key ring
Key #X: iteratively list all keys
Each key contains an ID and a key value.
2019/2/25
SUPnP -

12. Data Communication Unicast Multicast/Broadcast
For client-controller communication
A session key is kept on both the client and the controller
Messages are encrypted/decrypted using the session key
Multicast/Broadcast
For server-controller or server-server communication
All group members share the same (global) secret key
In our solution, we use LKH to maintain the secret keys
Messages are encrypted/decrypted using the LKH root key
2019/2/25
SUPnP -

13. Re-Key
Change the shared global secret key when node (group member) joins or leaves
Reason: Keep forward/backward secrecy
Backward secrecy
New comers cannot read past secrets before they join
Forward secrecy
Members cannot read future secrets after they leave.
Re-Key Protocol Message: See later
2019/2/25
SUPnP -

14. Re-Key (Cont’d) Protocol Message: CMD – KEY_UPDATE
A broadcast command sent from the key server:
Command SEQ# should be the same if a key update message is divided and transmitted in several different packets.
Fields (nounce/algorithm/N-pack are in 32-bit big-endian byte order)
nounce: a randomly generated number
algorithm: the algorithm to encrypt the KeyRing in each KeyPack
N-pack: the number of KeyPacks in the message
Format of a KeyPack
Key-ID, length, encrypted<KeyRing>using key[Key-ID]
Reuse the KeyRing data structure.However
The ID of the KeyRing is set to {Key-ID + nounce} to verify the correctness of the decrypted KeyPack.
The “algorithm” field of the KeyRing is unused here.
Protocols should be encapsulated in command packets
2019/2/25
SUPnP -

15. An LKH Example (1/3)
A “Key Server” (a.k.a. Key Distribution Center, KDC, or Group Manager, GM) maintains a tree of keys
k14 k
k58
k12
k34
k56
k78 k1 k2 k3 k4 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8
2019/2/25
SUPnP -

16. An LKH Example (2/) Member Join
Modified keys 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 Enc{k’, k’14, k’34, k4}k4
Broadcast once to update all secret keys
k14 k
k58
k12
k34
k56
k78 k1 k2 k3 k4 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8
k’34
k’14 k’
{k’34}k3
{k’34}k4
{k’14}k12
{k’14}k’34
{k’}k’14
{k’}k58
2019/2/25
SUPnP -

17. An LKH Example (3/3) Member Leave
Modified keys 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
Also, broadcast once to update all secret keys
k14 k
k58
k12
k34
k56
k78 k1 k2 k3 k4 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8
k’34
k’14 k’
{k’34}k3
{k’14}k12
{k’14}k’34
{k’}k’14
{k’}k58
2019/2/25
SUPnP -

18. Network Expansion in LKH
TODO
An LKH implementation issue
Use FIXED network size (currently)
Can be a future work
2019/2/25
SUPnP -

19. Implementation Details
Packet Formats
Command Data Structure
Internal Variables
Cryptographic Algorithms
The Forwarder
The Key Server
2019/2/25
SUPnP -

20. SUPnP Packet Formats An SUPnP Packet
Fields (all in 32-bit big-endian byte order):
magic – fixed to 0x55596E9F
flag – indicates: encrypted, grouop-comm, ctrl-msg, crypto-algorithm, …
keyid – indicate the key used to encrypt
nounce – make encrypted message indistinguishable
length – message length (exclude header length)
cksum – checksum, XORed result of all the above fields
2019/2/25
SUPnP -

21. SUPnP Packet Format (Cont’d)
The SUPnP Packet is encapsulated in an UPnP packet (as a payload)
Determine a valid SUPnP packet
Check the magic number
Verify the checksum
XORed result of all the first six fields should be ZERO.
2019/2/25
SUPnP -

22. Command Data Structure
Commands are encapsulated in unencrypted SUPnP packets
Required hash or encryption/decryption are done by command handlers.
The data structure
Fields (seq and length in 32-bit big-endian byte order):
command – the actual command
seq – a sequence number (for maintaining request states, should be an ascendant value)
NO length field – the data length can be computed by the length field of a SUPNP packet header minus the control command header.
2019/2/25
SUPnP -

23. Internal Variables Node type Bypass plaintext Number of secret keys
A node can be a SUPnP client or server, depends on its application
Bypass plaintext
Allow receipt of unencrypted messages
Number of secret keys
For a client: support only unicast communication – always be 1
For a server: support both unicast and multicast/broadcast communication – depends on the LKH tree size
Key Rings
Store secret key(s)
Used cryptographic algorithm
Currently support only AES
2019/2/25
SUPnP -

24. Cryptographic Algorithms
Using the OpenSSL library
Hash Functions
SHA1 (256-bit)
MD5 (128-bit)
Encryption Functions
AES (256-bit) CBC
2019/2/25
SUPnP -

25. The Forwarder Object The Problem – Distinguish the traffic direction
Transform secret data between the unicast network and group communication network.
The Problem – Distinguish the traffic direction
Two solutions
Solution I: implicit method
Message-ID + group communication flag
Solution II: explicit method
Using extra flags to maintain (has to specified in data-send function calls)
2019/2/25
SUPnP -

26. The Key Server A special application of the SUPnP framework
Maintain the key tree and all the secret keys
Maintain group membership: Handle node joins/leaves
Problem!
Should it be integrated with the UPnP controller?
2019/2/25
SUPnP -

27. Other Related Services
The Authentication Server
A traditional application of the SUPnP framework
Authenticate the system user
Broadcast user identity to other servers in the group
The Profile Server
Another traditional application of the SUPnP framework
Based on the authenticated system user, provide profile roaming service.
2019/2/25
SUPnP -