Security

Tracker : ISSUE-3

Enabling application access to Home Network devices and content available on such devices raise several security and privacy concerns. Addressing user security and privacy is of primary importance for a conforming specification. This imply that some features may have to be "restricted" in order not to compromise user security. This may have an impact on the flexibility of these specifications, so a delicate balance between user experience and security needs to be found.

This section list possible threats that a conforming specification have to deal with and possible solutions to reduce risks for the user. This section is not intended as an exhaustive list of problems and solutions but is intended to provide some directions for further investigation

Threats

Security

Malicious attacks
- An external server can control an Home Network device (e.g. send spam to your printer)
- A vulnerability in one of the Home Network devices can be used as a back door to get access to the Home Network
- Denial of service - repeated requests for resources could render a Home Network device/application/service unusable
Leaking of information from the home network to the Internet (e.g. content)
Some users inside the home network may allow external application unwanted access to home network devices (e.g. a family may wish to prevent any website that the children view on their PCs or phones from being able to query and/or control other devices)

Privacy

3rd party visibility into content (e.g. movies) available in the HN.
3rd party visibility of type of devices available in the home network
3rd party visibility of applications in use/installed (e.g. don't expose the fact that my home security system is part of my HN)

Potential solutions

The list of techniques listed in this section are not mutually exclusive but can be combined to provide more flexibility in handling user security.

Home Network access allowed only to Trusted applications

In order for the application to be able to access Home Network functionalities exposed by the UA, it needs to be trusted (by default is untrusted)
There could be different way to identify if an application is trusted and also different trust levels (and associated permissions).

How to determine the trust level of an application (several may apply)

Asking the user to authorize the application (via a dialog, a white list or other means)
Using a white list that is provided by the platform (e.g. surrendering control to service providers)

Trust levels options (mutually exclusive)

just 2 levels (trusted/untrusted)
- Trusted have full access to the Home Network capabilities
- Untrusted have NO access to the Home Network capabilities
multiple trust levels and associated permissions (like user in OSes)
- identify different subgroups of capabilities that the UA is able to expose
- associate these capabilities to a permission and each group to a subset of permissions
don't define generic trust levels but let the user decide on a "per action" base (see Modular access to HN Services and Content below)

Device Pairing

Pairing operation (using a PIN/password) is needed before devices can communicate
- The user is prompted to authorize the communication. Note that this could lead to a Potential denial-of-service.
- The user need to enter a (numeric) PIN or alphanumeric password
  - Numeric PIN may be easier to enter with traditional remote controls
  - A "default" PIN could be defined as common in other standards.
- The pairing could be one way (the control device make a "log in" into the controlled device) or two ways (devices needs to authorize each other)
Pairing Expiration: having pairing expire after a while could provide more security. In some scenarios thought, having the ability to configure it permanently allow for a better user experience. For example a user may have the Home Network devices configured by a technician. This is also very important for people with disabilities that may be unable to configure devices themselves.

Device Information only visible to the user

Exposing information about services, content and devices in the Home Network to an application is a potential privacy leak. This could be minimized allowing the application to only get access to:

an identifier for the device/content/service
an API to ask the UA to show more information about the content/service/device in some specific usecases, e.g.:
- ask the user to authorize a specific device to perform a given action
- show the user additional details about a specific device/ piece of content

This mechanism could limit the application flexibility but increases the user privacy.

An alternative approach could be to limit the application ability to access this information until the application has been explicitly authorized by the User, or has successfully paired with the device.

Modular access to Home Network Services and Content

One possible approach could be to consider each service as a separate "functionality" that the device has to authorize, in a similar fashion as Apps on mobile phones need to be authorized to access specific functionalities provided by the platform. The main difference in this case is that services available in the Home Network change over time, and also there isn't an installation process for web applications. Furthermore such approach would need a way to uniquely identify services (potentially across different home networking protocols) and expose relevant information for the user to understand what is actually authorizing. Such a technique would be then specification what would decide to enable a level interface for communication between devices/applications, which is not explicitly aware of different services