Re: Notes on W3C WoT Security Use Cases

One particular security issue we're grappling with on Mozilla's WoT gateway
implementation is the problem of secure access to a WoT API on a local
network when the outside Internet connection goes down. Here's a use case...


*A user is controlling the lights in their home from a smartphone using a
web app which uses a WoT API hosted via HTTPS by a gateway on the home
network. When the home Internet connection goes down the HTTPS URLs of the
WoT API can no longer be reached because HTTPS relies on DNS which requires
an active Internet connection to resolve domain names in order to verify
the identity of a web server. The user is unable to turn their lights on
and off until their Internet connection comes back up.*

A client inside the local network could still connect to the gateway using
its local IP address or a .local domain broadcast using mDNS, but this
would only be available over a plain HTTP connection because HTTPS can by
definition not be used on a local network without a self-signed certificate
which will trigger a browser exception. If we assume that not all of the
many connected devices on the home network are trusted then this creates an
attack vector for a man-in-the-middle attack where a password or API token
is intercepted by a malicious device.

Making an HTTPS connection to a device on the local network continue to
work when the Internet connection goes down is quite a challenge for both
home and industrial applications. We've been discussing some potential
solutions <https://github.com/mozilla-iot/gateway/issues/171> to this
problem, but I'd be interested if anyone else in the group has come up
against the same issue?

Ben

On 12 July 2017 at 14:07, Mccool, Michael <michael.mccool@intel.com> wrote:

>
> Relevant to this is the comment made by Mozilla recently in their
> proposal: the distinction between "local" and "global" networking is
> important since there will typically be a "bridge" mapping the local to the
> global (eg a Bluetooth wearable will probably expose its resources through
> a bridge that in turn exposes a http/tcp interface or whatever).
>
> Michael
>
> -----Original Message-----
> From: Soumya Kanti Datta [mailto:Soumya-Kanti.Datta@eurecom.fr]
> Sent: Wednesday, July 12, 2017 14:46
> To: Mccool, Michael <michael.mccool@intel.com>; Reshetova, Elena <
> elena.reshetova@intel.com>
> Cc: public-wot-wg@w3.org; public-wot-ig@w3.org
> Subject: Re: Notes on W3C WoT Security Use Cases
>
> +1 for Michael's proposal.
>
> Soumya
>
> Research Engineer, EURECOM, France | +33658194342 | @skdatta2010 |
> http://iot.eurecom.fr | Skype id: soumyakantidatta
>
> On 12-07-2017 18:10, Mccool, Michael wrote:
> > The other thought that came into my mind when Soumya and I were talking
> is that we can do a categorization by "technologies".   For instance, there
> is a difference in security possible between "Local" networking (Bluetooth,
> Zigbee, etc) and "Global" networking (TCP, HTTP, etc).   Think of this as
> another "axis" along which we can characterize the problem and scenarios.
> >
> > Michael
> >
> > -----Original Message-----
> > From: Soumya Kanti Datta [mailto:Soumya-Kanti.Datta@eurecom.fr]
> > Sent: Wednesday, July 12, 2017 14:37
> > To: Reshetova, Elena <elena.reshetova@intel.com>; Mccool, Michael
> > <michael.mccool@intel.com>
> > Cc: public-wot-wg@w3.org; public-wot-ig@w3.org
> > Subject: Re: Notes on W3C WoT Security Use Cases
> >
> > Hi Elena,
> >
> > I think privacy is the main aspect here. There can be other factors like
> control over the private data - one may want to share one's body temp with
> doctor in case of fever. For emergency or law enforcement situations, much
> more data need to be shared.
> >
> > I am not sure if the security tasks are taking care of access control or
> it is in the scope.
> >
> > Best regards,
> >
> > Soumya
> >
> > Research Engineer, EURECOM, France | +33658194342 | @skdatta2010 |
> > http://iot.eurecom.fr | Skype id: soumyakantidatta
> >
> > On 12-07-2017 17:27, Reshetova, Elena wrote:
> >> Hi Soumya,
> >>
> >> Thank you very much for your use case!
> >> I guess the main differentiating property of this use case would be
> privacy (since data in wearables are coming from individuals). Could you
> think of more differentiating factors in this use case?
> >>
> >> Best Regards,
> >> Elena.
> >>
> >>> -----Original Message-----
> >>> From: Soumya Kanti Datta [mailto:Soumya-Kanti.Datta@eurecom.fr]
> >>> Sent: Wednesday, July 12, 2017 12:22 PM
> >>> To: Mccool, Michael <michael.mccool@intel.com>; Reshetova, Elena
> >>> <elena.reshetova@intel.com>
> >>> Cc: public-wot-wg@w3.org; public-wot-ig@w3.org
> >>> Subject: Re: Notes on W3C WoT Security Use Cases
> >>>
> >>> Hello All,
> >>>
> >>> One more use case from my side. I did a study with some students on
> >>> wearable devices. We found that most of them do not use "https" or
> >>> encrypt the data they are sending to a cloud. I think we can extend
> >>> our scope to cover fitness trackers/wearables as well.
> >>>
> >>> I will join the Security TF in the WG from now on.
> >>>
> >>> Thanks,
> >>>
> >>> Soumya
> >>>
> >>> Research Engineer, EURECOM, France | +33658194342 | @skdatta2010 |
> >>> http://iot.eurecom.fr | Skype id: soumyakantidatta
> >>>
> >>> On 12-07-2017 13:45, Mccool, Michael wrote:
> >>>> Notes from security use cases discussion today in the F2F.
> >>>> (These are cc'd to the public WoT IG/WG lists so be careful with
> reply-to-all).
> >>>>
> >>>> Have come up with some things in our threat model.. but are missing
> >>>> more
> >>> specific use cases.   Want to find scenarios that are different from
> the security
> >>> viewpoint.
> >>>> First thing we tried to define was the "home" use case (see link).
> >>>> https://github.com/ereshetova/wot/blob/master/security-
> >>> privacy/SecurityScenarios.md
> >>>> Wand to add additional scenarios to this document... have moved the
> >>>> scenarios
> >>> out of the threat model into a separate document.
> >>>> For home scenario, privacy is important, for instance; it may be
> >>>> more or less
> >>> important in other scenarios (eg more in medical, less in industrial,
> etc).
> >>>> Don't really need details, just an idea of which environments are
> important.
> >>>>
> >>>> Why?  To be able to define levels of security for implementation.
> >>>> Different
> >>> standards apply to different use cases, and also interoperability
> >>> may or may not be desirable between different ecosystems if they
> >>> have different security and privacy standards they need to satisfy.
> >>> Cross-domain information exchange permitted and when?
> >>>> Question from google: do we consider security and privacy together,
> >>>> or
> >>> separately?
> >>>> Response: together for this discussion, but separately later.
> >>>> Also, use cases
> >>> important for more than security.
> >>>> Privacy: only relevant if there are people involved.  People have
> classes:
> >>> employees, citizens, police, nurse/doctor, owner, etc.
> >>>> Issue: indirect information about people possible, eg. heat systems
> >>>> -> people
> >>> home or not.   Also issue of tying data about people to a particular
> person, vs
> >>> aggregate or anonymized information.
> >>>> What are other good differentiating feature:
> >>>> Critical infrastructure (failure -> safety  or physical security
> issue issue).    Level
> >>> of impact.
> >>>> Cost (failure -> equipment damage).
> >>>> Confidentiality (failure -> leakage of sensitive information, which
> >>>> could be
> >>> personal, corporate, or municipal, or governmental (eg national
> >>> security))
> >>>> TODO: look at existing standards and frameworks, such as the IIC,
> >>>> to find
> >>> additional differentiating features
> >>>> Might be able to manage with semantic classes using differentiating
> factors.
> >>> For example, could restrict data to devices with an appropriate level
> of security.
> >>>> Additional Use Cases:
> >>>>
> >>>> Medical: Medical devices communicating with hospital IT system and
> >>> monitoring patients.  This means they carry personal patient data
> >>> and will be subject to privacy legislation.  Critical, people  =>
> >>> High security and privacy requirements.
> >>>> Industrial Automation: Industrial use cases not directly monitoring
> >>>> people, eg a
> >>> fully automated factory.  Cost => security requirement.
> >>>> Corporate Employee Monitoring /{Office, Manufacturing}: Corporate
> >>>> use cases
> >>> including monitoring of people, which might be office or industrial
> >>> (eg manufacturing).
> >>>> Smart Cities/Building/Campus: Municipal system monitoring,
> >>>> including
> >>> monitoring of both infrastructure and people (both citizens and
> employees).
> >>> Failures may have both privacy and safety implications.  Law and order.
> >>> Emergency services (Fire and EMG).
> >>>> Mobile: personal devices (including voice recog access points)
> >>>> communicating
> >>> with IoT devices.
> >>>> Scripting API, post-data-consuming vs exposed side.  How does
> >>>> security look
> >>> from the consumer viewpoint?  From the exposed data viewpoint?
>  Consumer is
> >>> the data user; exposer is data provider.  But need to consider flow of
> both data
> >>> and commands; latter can cause a safety issue, for instance.   To
> further consider
> >>> direction of flow of data and threats, who is attacker, etc.
> >>>> Could be an issue, for instance, with an exposed thing producing
> >>>> false data (eg
> >>> a security sensor) that influences a system consuming that data,
> >>> causing a physical security risk.
> >>>> -----Original Message-----
> >>>> From: Reshetova, Elena
> >>>> Sent: Wednesday, July 12, 2017 08:29
> >>>> To: Mccool, Michael <michael.mccool@intel.com>
> >>>> Subject: Link to the security use cases doc
> >>>>
> >>>> Michael,
> >>>>
> >>>> Here is the link to the security scenarios/use cases doc:
> >>> https://github.com/ereshetova/wot/blob/master/security-
> >>> privacy/SecurityScenarios.md
> >>>> It has the home scenario now moved from threat document, as well as
> >>> tentative placeholders for two more use cases, but let's see how the
> >>> discussion goes today.
> >>>> Best Regards,
> >>>> Elena
> >>>>
>
>