UPnP Security Vic Lortz Chair, Security WC Intel Corporation

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

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

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

What’s Needed: Security 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

Spec documents DeviceSecurity – primary service 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

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).

Benefits and Costs Benefits Costs Protects from “bad guys” 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

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

UPnP Security Fundamentals

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

Permissions XML elements defined by device manufacturer 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>”

Access Control Lists <entry> <subject> {<hash> or 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>

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

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

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

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

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

Authorization Certificates 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

The Power of Delegation 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)

Scenarios

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)

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

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

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

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

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

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)

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

Remote Plugfest Learnings

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

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

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

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

For the interconnected lifestyle