Transcript Design and Implementation of a Secure UPnP Environment

Design and Implementation of a
Secure UPnP Environment
Distributed Computing and Network Security Lab
National Taiwan University
Last Update: 2006-09-25
<Project Members>
Chun-Ying Huang, Jiunn-Jye Lee, Chia-Chang Hsu,
Ssu-Ying Lee, Che-Jui Hsu, Chou-Chin Kang, Chia-Wei Hsu
2016/5/24
SUPnP - DCNSLab@NTU
1
Outline
•
•
•
•
•
•
System Architecture
UPnP Introduction
Project Goal
Protocol Design
Implementation
Other Related Services
2016/5/24
SUPnP - DCNSLab@NTU
2
System Architecture
Wireless
contactless identity
(RFID/SmartCard)
Name Server
Authenticator
Reader
DCNSLab@NTU
Wireless
contactless identity
(RFID/SmartCard)
Certificate
Authority
Reader
Controller
Data Server
Client
Profile Server
Data Server
Data Server
2016/5/24
Data Server
SUPnP - DCNSLab@NTU
Client
3
UPnP Introduction
• UPnP – Universal Plug-and-Play
– A controller maintains all network devices.
– Connect network devices seamlessly.
– Zero-configuration
• The Problem
– No secure data transmission
protocol for the UPnP
environment.
2016/5/24
SUPnP - DCNSLab@NTU
4
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
2016/5/24
SUPnP - DCNSLab@NTU
5
Protocol Design
•
•
•
•
•
•
•
Design Philosophy
Assumptions
Programming Interfaces
Node Registration
Data Communication
Re-Key
Network Expansion
2016/5/24
SUPnP - DCNSLab@NTU
6
Design Philosophy
• Layered design: Increase compatibilities
APP Readers
(Client)
APP Servers
(Server)
APP Auth Server
(Server)
APP Forwarder
(Server)
APP Key Manager
(Server)
SUPnP
SUPnP
SUPnP
SUPnP
SUPnP
UPnP
HTTP/HTTPS
TCP/UDP
IP
PHYSICAL NETWORK
2016/5/24
SUPnP - DCNSLab@NTU
7
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.
2016/5/24
SUPnP - DCNSLab@NTU
8
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_login(user-ID, password)
– 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()
2016/5/24
SUPnP - DCNSLab@NTU
9
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
Client
• 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
Key Server
REG REQUEST: SEQ#,
IDLEN, ID
, RND#1, IDLEN, ID
REG REPLY: SEQ#, SALT
REG CONFIRM:
SEQ#, H(RND#1, H(SA
LT, PWD)), IDLEN, ID
REG DONE:
yRing)
ID, ENCS-KEY(RND#2, Ke
SEQ#, RND#2, IDLEN,
S-KEY = H(RND#2, H(SALT, PWD))
Protocols should be encapsulated in
command packets
2016/5/24
SUPnP - DCNSLab@NTU
10
Node Registration (Cont’d)
• “KeyRing” Format
ID
algorithm
N-key
Key-#1
Key-#2
……
Key-#N
• 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.
2016/5/24
SUPnP - DCNSLab@NTU
11
Data Communication
• Unicast
– 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
2016/5/24
SUPnP - DCNSLab@NTU
12
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
2016/5/24
SUPnP - DCNSLab@NTU
13
Re-Key (Cont’d)
• Protocol Message: CMD – KEY_UPDATE
– A broadcast command sent from the key server:
nounce
algorithm
N-pack
KeyPack#1
KeyPack#2
KeyPack#N
……
• 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.
2016/5/24
SUPnP - DCNSLab@NTU
Protocols should be
encapsulated in
command packets
14
An LKH Example (1/3)
• A “Key Server” (a.k.a. Key Distribution Center, KDC,
or Group Manager, GM) maintains a tree of keys
k
k14
k58
k12
2016/5/24
k34
k56
k78
k1
k2
k3
k4
k5
k6
k7
k8
m1
m2
m3
m4
m5
m6
m7
m8
SUPnP - DCNSLab@NTU
15
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
2016/5/24
k’
k
{k’}k’14
{k’}k58
k’14
k14 {k’14}k12
{k’14}k’34
k58
k’34
k34 {k’34}k3 k56
{k’34}k4
k12
k78
k1
k2
k3
k4
k5
k6
k7
k8
m1
m2
m3
m4
m5
m6
m7
m8
SUPnP - DCNSLab@NTU
16
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
2016/5/24
k’
k
{k’}k’14
{k’}k58
k’14
k14 {k’14}k12
{k’14}k’34
k58
k’34
k34 {k’34}k3 k56
k12
k78
k1
k2
k3
k4
k5
k6
k7
k8
m1
m2
m3
m4
m5
m6
m7
m8
SUPnP - DCNSLab@NTU
17
Network Expansion in LKH
• TODO
– An LKH implementation issue
– Use FIXED network size (currently)
– Can be a future work
2016/5/24
SUPnP - DCNSLab@NTU
18
Implementation Details
•
•
•
•
•
•
Packet Formats
Command Data Structure
Internal Variables
Cryptographic Algorithms
The Forwarder
The Key Server
2016/5/24
SUPnP - DCNSLab@NTU
19
SUPnP Packet Formats
• An SUPnP Packet
magic
flag
keyid
nounce
length
cksum
……
• 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
2016/5/24
SUPnP - DCNSLab@NTU
20
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.
2016/5/24
SUPnP - DCNSLab@NTU
21
Command Data Structure
• Commands are encapsulated in unencrypted SUPnP packets
– Required hash or encryption/decryption are done by command
handlers.
• The data structure
command
seq
……
• 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.
2016/5/24
SUPnP - DCNSLab@NTU
22
Internal Variables
• Node type
– 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
2016/5/24
SUPnP - DCNSLab@NTU
23
Cryptographic Algorithms
• Using the OpenSSL library
• Hash Functions
– SHA1 (256-bit)
– MD5 (128-bit)
• Encryption Functions
– AES (256-bit) CBC
2016/5/24
SUPnP - DCNSLab@NTU
24
The Forwarder
• Object
– 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 datasend function calls)
2016/5/24
SUPnP - DCNSLab@NTU
25
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?
2016/5/24
SUPnP - DCNSLab@NTU
26
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.
2016/5/24
SUPnP - DCNSLab@NTU
27