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 2019/2/25 SUPnP - DCNSLab@NTU

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

System Architecture 2019/2/25 SUPnP - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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

Design Philosophy Layered design: Increase compatibilities 2019/2/25 SUPnP - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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

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

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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

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 - DCNSLab@NTU

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 - DCNSLab@NTU

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 - DCNSLab@NTU