Design and Implementation of a Secure UPnP Environment

1. 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 SUPnP - DCNSLab@NTU

2. Outline • System Architecture • UPnP Introduction • Project Goal • Protocol Design • Implementation • Other Related Services SUPnP - DCNSLab@NTU

3. System Architecture SUPnP - DCNSLab@NTU

4. UPnP Introduction • UPnP – Universal Plug-and-Play • A controller maintains all network devices. • Connect network devices seamlessly. • Zero-configuration • The Problem • No secure data transmissionprotocol for the UPnPenvironment. SUPnP - DCNSLab@NTU

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

6. Protocol Design • Design Philosophy • Assumptions • Programming Interfaces • Node Registration • Data Communication • Re-Key • Network Expansion SUPnP - DCNSLab@NTU

7. Design Philosophy • Layered design: Increase compatibilities SUPnP - DCNSLab@NTU

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

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_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() SUPnP - DCNSLab@NTU

10. 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 SUPnP - DCNSLab@NTU

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

12. 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 SUPnP - DCNSLab@NTU

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

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} toverify the correctness of the decrypted KeyPack. • The “algorithm” field of the KeyRing is unused here. Protocols should beencapsulated incommand packets SUPnP - DCNSLab@NTU

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

16. {k’}k’14 {k’}k58 k’ k {k’14}k12 {k’14}k’34 k14 k’14 k58 {k’34}k3 {k’34}k4 k12 k’34 k34 k56 k78 k2 k4 k1 k3 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8 An LKH Example (2/) • Member Join • Modified keysk  k’k14  k’14k34  k’34 • Key distributionEnc{k’}k58Enc{k’, k’14}k12Enc{k’, k’14, k’34}k3Enc{k’, k’14, k’34, k4}k4 • Broadcast once to update all secret keys SUPnP - DCNSLab@NTU

17. {k’}k’14 {k’}k58 k’ k {k’14}k12 {k’14}k’34 k14 k’14 k58 {k’34}k3 k12 k’34 k34 k56 k78 k2 k4 k1 k3 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8 An LKH Example (3/3) • Member Leave • Modified keysk  k’k14  k’14k34  k’34 • Key distributionEnc{k’}k58Enc{k’, k’14}k12Enc{k’, k’14, k’34}k3 • Also, broadcast once to update all secret keys SUPnP - DCNSLab@NTU

18. Network Expansion in LKH • TODO • An LKH implementation issue • Use FIXED network size (currently) • Can be a future work SUPnP - DCNSLab@NTU

19. Implementation Details • Packet Formats • Command Data Structure • Internal Variables • Cryptographic Algorithms • The Forwarder • The Key Server SUPnP - DCNSLab@NTU

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

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

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

23. 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 SUPnP - DCNSLab@NTU

24. Cryptographic Algorithms • Using the OpenSSL library • Hash Functions • SHA1 (256-bit) • MD5 (128-bit) • Encryption Functions • AES (256-bit) CBC SUPnP - DCNSLab@NTU

25. 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 data-send function calls) SUPnP - DCNSLab@NTU

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

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