Considerations for certain IoT based services
slides-iotsiws-considerations-for-certain-iot-based-services-00

Position Paper for the IoT Semantic Interoperability Workshop

Considerations for certain IoT based services

Ben Campbell <ben@nostrum.com> Robert Sparks <rjsparks@nostrum.com>


1. Who owns IoT devices?

End users often purchase consumer-oriented Internet-of-Things (IoT) elements as
they would any other home appliances or tools. They expect to own such devices
the same as they would any other purchases. This ownership interest implies that
users should be able to control how those devices share information, what
services they work with, and what features are enabled. Users expect devices
that they own to continue to be useful for the reasonable future, even if the
manufacturer decides to terminate service.

1. Trusted Services for Device Control

Many smart device products and related frameworks, especially in the home
automation market, use a "cloud-based" control model, following the
"Device-to-Cloud", or  the "Device-to-Gateway" patterns [RFC7542] where the
gateway must communicate with the cloud for normal operation. For the purposes
of this discussion, "cloud-based" means that the device monitoring and control
framework is hosted as a service, either by the manufacturer or a third party.
Devices typically communicate to the service across the Internet, while end
users interact with the service via web pages or mobile applications.

There are several motivations for application service providers to adopt a
cloud-based approach. Hosted services can offer benefits to the end user. For
example, cloud-based frameworks often provide remote access, integration with
automation services such as [IFTTT], and automatic backup of device related
configuration and data. And of course, providers get to collect valuable
information about user behavior. Cloud-based services make customer lock-in
easier.

But there are some serious privacy related downsides to the cloud-based
approach.  Cloud-based frameworks often force end users to trust application
service providers with their data. Home automation data can paint detailed
pictures of user habits. For example, energy usage data alone can indicate when
users are at home or away, awake or asleep, on vacation, or even bathing[Tien].
Adding lighting patterns, thermostat settings, coffee maker operation, and
television viewing data can reveal much more.  Providers take on the
responsibility for that data, with potential liability for any misuse [O'Brien].
Recent events suggest that the application service provider may become a target
for subpoenas [O'Toole]. Even application service providers that protect the
data from inspection by the themselves through encryption can capture
information using techiniques such as traffic analysis.

If a cloud-based service becomes compromised, attackers could gain control over
home automation devices, even to the point of unlocking doors and turning off
alarms en masse.  If the service or the user's Internet connection fail, the
user may completely lose device control.

End users need to be able to make rational choices about the information they
share with application service providers. Cloud-based services are often offered
on an "all-or-nothing" basis, where customers must either share the information,
or not to use the service at all.

2. Local Device Control

Many of these issues can be mitigated with a "local control" approach, where the
control framework is hosted on premise. In the case of home automation, device
control would be executed on devices or systems physically present in the home.
With locally controlled frameworks, users can minimize the data that leaves
their homes in the first place. It reduces the opportunity for mass compromise
of home-automation devices. And it can continue to operate when the user's
internet connection fails.

Application service providers can still provide rendezvous services to allow
users to securely access locally-hosted services from remote locations.
Providers can provide automatic backups of encrypted data without having access
to the clear text.

Integration with third-party automation frameworks such as IFTTT is still
possible with a mixed approach.  This suggests that even services that are
primarily "locally controlled"  will have some features that require sharing
data with the cloud.  Users need the ability choose whether to use such
features, so that they can control what data is  shared. This choice needs to be
reasonably granularly; a choice between "enable all cloud features" vs "disable
all cloud features" is not very satisfying.

3. Customer Capture

The aspect of "capturing" the customer is often key in building business models
around home automation services, and in general, any service that use IoT
elements.  This pressures design decisions towards tightly controlling how the
elements can be accessed.  "Captive" deployments force the elements to contact a
central service, and do not allow direct access to those elements without going
through the service.

4. Service Lifecycle

Such deployments, particularly when the central service is cloud-based, risk
overlooking several important operational life-cycle scenarios. It needs to be
possible to make significant changes to the service infrastructure, such as
underlying cloud technologies, without abandoning deployed IoT elements.
Designers need to consider how deployed elements should behave if the service is
suddenly and permanently disabled, gracefully retired, or merged into a
different service.  As was the case with hard-coding IP addresses and DNS names
into applications, there is a high potential for surprising consequences when
elements assume the central service will always be there [RFC7452].  This
potential is amplified as the number of participating elements increases,
particularly those that are difficult to physically access.

5. Impacts on data and information modeling

The information and data models for managing IoT deployments need to include the
concepts that allow changing how and when the IoT elements interact,
particularly with centralized services, to address both short and long term
service outages, changes in fundamental service infrastructure, and the
potential for service retirement.

The models should allow application designers and operators the flexibility to
separate components of data control into logical containers for management,
allowing different policies to be constructed for handling local information,
and information that needs to be made available to remote services.

References:

[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
          "Architectural Considerations in Smart Object Networking", RFC 7452, DOI
          10.17487/RFC7452, March 2015, <http://www.rfc-editor.org/info/rfc7452>.

[IFTTT] https:/ifttt.com

[Tien] "New 'Smart Meters' for Energy Use Put Privacy at Risk", EFF Deeplinks
        Blog, March 10, 2010,
<https://www.eff.org/deeplinks/2010/03/new-smart-meters-energy-use-put-privacy-risk>.

[O'Brien] O'Brien, H. Michael, "The Internet Of Things: Liability Risks For Tech
          Cos.", Law 360, July 20, 2015,
<http://www.law360.com/articles/680256/the-internet-of-things-liability-risks-for-tech-cos>.

[O'Toole] O'Toole, James, "Cops can access your connected home data", CNN Money,
          June 16, 2014,
<http://money.cnn.com/2014/06/16/technology/smart-home-footage/index.html>.