UPnP Security

1. UPnP Security Vic Lortz Chair, Security WC Intel Corporation

2. Agenda • Introduction • Fundamentals: security mechanisms and protection for each phase of UPnP • Scenarios • Remote plugfest learnings

3. Introduction UPnP Today • UPnP is about empowering ordinary people • automatic networking • no need for technical expertise • convenient, “it just works” • presumes a secure network

4. Introduction The Expanding Universe • Wireless, apartments, dorms, hotels, enterprise networks… • Remote access • Hackers • Viruses

5. Introduction What’s Needed: Security • Scenarios and requirements defined early 2001 • Security Working Committee established August, 2001 • Version 0.8 of spec docs completed March, 2002 • Sample implementations and 3rd plugfest underway

6. Introduction Spec documents • DeviceSecurity – primary service • SecurityConsole – service for publishing keys and names, distributing certificates • DeviceStealth – service for securing discovery • AuditService – service for event logs (not just security-related) • SecureDevice – device template, contains overall architectural description, secure event mechanism

7. Introduction Current Status • Sample implementations: Intel, LGE, Siemens (2 independent), Sony • Microsoft is enhancing test tool • On track to complete DeviceSecurity and SecurityConsole services by end of 2002. • DeviceStealth, secure eventing, and AuditService to follow soon • First customer: IGD V2 (A/V also interested).

8. Introduction Benefits and Costs • Benefits • Protects from “bad guys” • Enables high-value services (e.g., remote power metering, medical monitoring) • Costs • Additional code in devices, cycles to do crypto • Larger packet sizes on network • Incompatible with legacy UPnP (this is a feature) • Some configuration is required • Challenge is to minimize configuration without losing security

9. Version 2 (best guess) • V2 solution will probably be almost identical to V1 solution • Encryption strategy probably will be different • Secure eventing definitely will be different • V1 UPnP Security is already very close to WS-Security (and related specs) • V2 UPnP Security will be a proper subset of WS-Security • Microsoft is working to make sure UPnP requirements are addressed in WS-Security

10. UPnP Security Fundamentals

11. Fundamentals Principals • Principals are “raw” public keys (no expensive Public Key Infrastructure) • Key hashes are principal identifiers • Users can assign local names to keys • Key values are passed by SOAP (for control actions) or in self-signed X.509 certificates (for presentation pages) • Groups of keys can be defined

12. Fundamentals Permissions • XML elements defined by device manufacturer • Permissions are abstractions (do not map 1:1 onto UPnP actions) • Devices can also define named sets of permissions (profiles) • Can include parameters • E.g., “<read/>”, “<Administrator/>”, “<user><name> Frodo </name></user>”

13. Fundamentals Access Control Lists <entry> <subject> {<hash> or <any/>} </subject> <access> {permission elements or <all/>} </access> <valid> {optional <not-before> and/or <not-after>} </valid> </entry>

14. Fundamentals Discovery: DeviceStealth • Device advertises itself as generic “SecureDevice” or “BasicDevice” • Full device description obtained via access-controlled SOAP actions • IsTypeSupported() • GetDeviceDetails()

15. Fundamentals Control: Secure SOAP • XML Dsig-based signatures and anti-replay in SOAP header • SetSessionKey() – binds symmetric keys with public keys • DecryptAndExecute() – for privacy, encrypts and tunnels entire HTTP packet • Minimal (null) canonicalization • Crypto algorithms: RSA, SHA1-HMAC, AES

16. Fundamentals Secure SOAP Message HTTP Header SOAP Envelope SOAP Header (XML signature, {key info}, Freshness block for anti-replay) SOAP Body (UPnP Action)

17. Fundamentals Secure Eventing • Requires implementation of DeviceSecurity to establish session keys • Secure subscribe call includes 4 new headers • KEY-ID, IV, KEY-SEQ, HMAC • Events are encrypted and signed using the designated session keys

18. Fundamentals Presentation Pages • Device (server) authentication with self-signed X.509 certificate • Browser (client) also authenticates with self-signed certificate • Permissions and ACLs also apply to presentation pages, based on the public key in the browser certificate

19. Fundamentals Authorization Certificates • Equivalent to signed ACL entries • also include issuer, device public key ID, and signature • Enable small ACLs • Support constrained delegation of permissions

20. Fundamentals The Power of Delegation • Provides scalable access control • applicable to hierarchical organizations • Enables flexible business models • subcontractors • constrained delegation limits powers (liability) • Auditable (better than sharing passwords)

21. Scenarios

22. Fundamentals Bootstrapping Trust • Need some way to establish trust of control point keys • Public keys can be sent in the clear, but need out-of-band mechanism to bootstrap trust • Hardware-based (e.g., IR) • Default method (SecurityConsole)

23. Scenarios New Device Introduction Security Console Device discovery GetPublicKeys() TakeOwnership()

24. Scenarios Control Point Introduction Control Point Security Console discovery PresentKey()

25. Scenarios Access Control Configuration Security Console Device (prior TakeOwnership…) GetDefinedPermissions() AddACLEntry()

26. Scenarios Control Point Uses Device Control Point Device GetPublicKeys() SetSessionKeys() SomeAction() + sig or DecryptAndExecute()

27. Scenarios Access Control Using Certs Security Console Control Point Device GetMyCertificates() CacheCertificate() optional step… SomeAction() + sig + cert(s)

28. Summary • UPnP Security 1.0 is nearly complete • V2 Security will be similar, especially in the areas of trust bootstrapping and authorization • Your customers will expect and demand security • Toolkits and O/S support will be available soon (stay tuned)

29. Collateral • http://forum.upnp.org/archives/security.html • http:www.upnp.org/members/repository.asp

30. Remote Plugfest Learnings

31. Motivation • Two and three day plug-fests are not long enough to resolve complicated issues • Fixing some of these problems can be very invasive to code • Current economic climate dictates that travel to numerous plugfests is infeasible

32. Basic Solution • UPnP is a network-based protocol, so let’s use the Internet • Rather than use SSDP, explicitly load description documents using URLs communicated out-of-band • Firewall workarounds: • Put devices outside firewall • Use a VPN • Target a few actions every week between companies, testing during agreed times • Requires commitment for at least one person at each company to be available for 1 to 2 hours a week

33. Impact • Raises level of assurance that implementations will work together • Don’t come to F2F plugfests hoping things will “just work” • Makes F2F plugfests more productive • Allows implementers to work on real issues, instead of tiny mistakes • Allows for accurate communication of status for planning purposes

34. Acronyms • XML Dsig – XML Digital Signature • XML Enc – XML Encryption • SOAP – Simple Object Access Protocol • PKI – Public Key Infrastructure (e.g., X.509)

35. For the interconnected lifestyle