Copyright
©
2017
2017-2018
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
).
W3C
liability
,
trademark
and
permissive
document
license
rules
apply.
This document provides non-normative guidance on Web of Things (WoT) security and privacy. The Web of Things is descriptive, not prescriptive, and so is generally designed to support the security models and mechanisms of the systems it describes, not introduce new ones. However, a WoT system also has its own unique assets, such as a Scripting API and Thing Descriptions, that need to be protected and also have security and privacy implications.
We
define
the
general
security
requirements
for
a
Web
of
Things
system
using
a
threat
model.
The
WoT
threat
model
defines
the
main
security
stakeholders,
security-relevant
assets,
possible
attackers,
attack
surfaces,
and
finally
threats
for
a
WoT
system.
Using
this
generic
WoT
threat
model
as
a
foundation,
for
guidance,
it
should
be
possible
to
build
select
a
specific
set
of
security
objectives
for
a
concrete
WoT
system
implementation.
We
provide
several
examples
using
common
scenarios
based
on
home,
enterprise,
and
industrial
use
cases.
We
also
provide
more
general
guidance
on
suggestions
for
the
design
and
deployment
of
a
secure
WoT
system.
All
recommendations
are
linked
to
the
corresponding
WoT
threats
in
the
generic
woT
threat
model
in
order
to
facilitate
understanding
of
why
they
are
needed.
It is not the intention of this document to limit the set of security mechanisms that can be used to secure a WoT network. In particular, while we provide examples and recommendations based on the best available practices in the industry, this document contains informative statements only. Specific normative security aspects of the WoT specification are defined in the corresponding normative WoT documents for each WoT building block.
Check
that
This
content
is
should
be
consistent
with
the
summary
summaries
in
the
Security
sections
of
other
WoT
documents,
in
particular
the
WoT
Architecture
document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
Please contribute to this draft using the GitHub Issue feature of the WoT Security and Privacy Considerations repository.
This document was published by the Web of Things Working Group as a Working Group Note. Comments regarding this document are welcome. Please send them to public-wot-wg@w3.org ( subscribe , archives ).
A diff-marked version of this document is also available for comparison purposes.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This
document
was
produced
by
a
group
operating
under
the
W3C
Patent
Policy
.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
This
document
is
governed
by
the
1
March
2017
February
2018
W3C
Process
Document
.
Security
of
a
WoT
system
can
refer
to
the
security
of
the
Thing
Description
itself
or
the
security
of
the
Thing
the
Thing
Description
describes.
See
also:
For
details
on
the
Web
of
Things
architecture,
please
refer
to
the
following:
The lifecycle of a WoT device is similar to the lifecycles of other IoT devices and services. Iy may in fact be identical if a WoT Thing Description is being used simply to describe an existing device implemented using another standard. However, for discussion purposes we will use the generic lifecycle shown in Figure Figure 1 which includes the following states:
In
general
using
the
WoT
approach
should
"do
no
harm":
the
security
of
any
protocols
should
be
maintained.
The
Web
of
Things
systems
does
not
introduce
new
security
mechanisms,
but
should
preserve
the
functionality
and
security
of
existing
mechanisms.
We
also
have
the
following
requirements:
Due
to
the
large
diversity
of
devices,
use
cases,
deployment
scenarios
and
various
requirements
for
WoT
Things,
it
is
impossible
to
define
a
single
WoT
threat
model
that
would
fit
every
case.
Instead
we
have
created
describe
here
an
overall
WoT
threat
model
framework
that
can
be
adjusted
by
OEMs
or
other
WoT
system
users
or
providers
based
on
their
concrete
security
requirements.
This
framework
gives
a
set
of
possible
threats
that
implementers
should
consider,
but
which
may
or
may
not
apply
to
their
system.
When selecting suitable mitigations to the WoT threats described, it is important to consider various criteria that might increase the risk level for a particular WoT architecture, such as handing privacy-sensitive data, physical safety of individuals or the surrounding environment, high availability requirements, and so forth. In addition threat mitigations will always be limited by the capabilities of underlying devices, their list of supported security protocols, processes isolation capabilities, etc.
This section lists the primary WoT stakeholders.
Stakeholder | Description | Security goals | Edge cases |
---|---|---|---|
Device Manufacturer (OEM) |
Producer
of
the
HW
|
Don't
want
the
devices
they
make
to
be
used
in
any
form
of
|
|
or or System Installer |
Uses
devices
from
OEM
s
to
build
various
WoT
end
solutions
specific
to
particular
WoT
use
case(s).
An
OEM
might
simultaneously
be
a
|
Don't
want
their
WoT
network
to
be
a
target
of
any
attacks
(loss
of
reputation,
possible
legal
consequences
in
some
countries).
Want
to
satisfy
security
requirements
of
|
There
might
be
several
independent
|
|
|
Don't
want
their
data
to
be
exposed
to
any
other
|
Access
to
user
data
might
be
configurable
based
not
only
on
"who"
is
the
entity
accessing
the
data
|
|
An
entity
that
provisions
a
thing
with
the
security
root
of
trust
and
sets
up
the
initial
policies
on
who
can
provision/update/remove
scripts
to/from
the
WoT
|
Want
to
|
|
System Maintainer |
|
|
This section lists all WoT Assets that are important from a security point of view.
Asset | Description |
Who
should
have
access
(Trust Model) |
Attack Points |
---|---|---|---|
Thing Description (TD) |
Access
Control
policies
for
TDs
and
the
resources
it
describes
are
part
of
|
TD
owner:
full
access
Others: read only for minimal required part. |
Storage on thing itself, cloud storage, in-transfer (network) including TD updates. |
|
This includes all data that is produced or processed by the elements of a WoT system, i.e. sensor readings and their states, user configurations and preferences, actuator commands, video/audio streams, etc. Can be highly privacy sensitive and confidential. |
Different
Others: should have no access unless specifically allowed |
Storage
on
the
device
itself,
remote
|
|
This
includes
both
WoT
scripts
and
any
WoT
configuration
data
produced
and
owned
by
a
|
Others: no access |
Storage on the device itself, runtime memory representation, in-transfer only for initial provisioning and script updates |
WoT
Thing
Resources
and WoT Infrastructure Resources |
Resources should only be used for legitimate purposes and be available when required. |
|
WoT Interface |
WoT Controlled Environment |
WoT
devices
that
have
actuator
capabilities
are
able
to
affect
the
physical
environment
around
them.
Such
capability
must
only
be
used
by
authorized
entities
and
for
legitimate
|
|
WoT Interface |
WoT Behavior Metrics | Indirectly transmitted information (metadata) that represents measurements of a WoT system's behavior from which other information can be inferred, such as user presence. For example, the amount of communication between different things, the APIs used, distribution of communication over time, etc. | It should not be possible to collect/identify indirectly transferable information | In-transfer data and usage of WoT Interface |
WoT Basic Security Metadata | All required security metadata (keys, certificates etc.) that might be provisioned to the WoT device in order to be able to perform various security-related operations, such as authenticating another device or WoT client in the WoT network, authenticating remote authorization service in case the access control to WoT interfaces is done using tokens, etc. |
|
On
device
storage,
in-transfer
including
provisioning
and
updates
of
security
metadata.
|
The
term
Thing
Data
can
be
used
to
refer
to
either
Thing
System
User
Data
or
Thing
System
Provider
Data
.
If a WoT system supports dynamic installation of scripts inside WoT runtime, the following assets are added:
Asset | Description |
Who
should
have
access?
(Trust Model) |
Attack Points |
---|---|---|---|
WoT
|
Defines
who
can
provision,
install,
update,
and
remove
scripts
and
other
|
|
WoT Script Management Interface |
If
a
WoT
system
allows
co-existence
of
different
independent
Thing
providers
System
Providers
(tenants)
on
a
single
physical
device,
the
following
assets
are
added:
Asset | Description |
Who
should
have
access?
(Trust Model) |
Attack Points |
---|---|---|---|
WoT Runtime Isolation Policies |
Access
control
policies
for
isolating
co-existing
|
|
Storage on the thing itself, remote storage (if they are backed up to a remote storage), in-transfer for initial provisioning and policy updates |
The following adversaries are in-scope for the WoT threat model:
Persona | Motivation | Attacker type |
---|---|---|
Network Attacker | Unauthorized access or modification of any stakeholder's asset over the network. Denial of service. Inferring of non-public or privacy sensitive information. Taking control of the network component of a WoT system. Reasons: money, fame etc. |
Network
attack:
an
attacker
has
network
access
to
a
WoT
system,
is
able
to
use
WoT
Interface,
perform
|
Malicious Authorized User |
Unauthorized
access
of
private
data
of
any
other
|
Local
physical
access,
WoT
Client
interface
(smartphone,
web
interface,
washing
machine
interface,
|
Malicious Unauthorized User | Similar to Malicious Authorized User , but with no prior access to the WoT system (examples: guests in a house, guests in a factory). Denial of service attacks on WoT network. | Limited local physical network access, can use proximity factor |
Malware Developer | Unauthorized access or modification of any stakeholder's asset. Denial of service attacks on WoT network. Taking control of WoT system network components. Reasons: money, fame etc. | Unprivileged software adversary: application intentionally gets installed or code injected into WoT client (user's smartphone, browser, etc.) or in WoT runtime itself using available WoT Interfaces |
The general term Malicious User may be used to refer to either a Malicious Authorized User or a Malicious Unauthorized User .
If
in
a
WoT
system
allows
the
co-existence
of
different
independent
Thing
System
providers
(tenants)
on
a
single
physical
device,
the
following
adversaries
are
added:
Persona | Motivation | Attacker Type |
---|---|---|
Malicious
|
Tries
to
get
access
or
modify
other
|
Unprivileged
software
adversary:
|
The following adversaries are out of scope of the WoT threat model:
Persona | Motivation | Attacker Type |
---|---|---|
Malicious OEM | Intentionally installs HW, firmware or other lower SW level backdoors, rootkits etc. in order to get unauthorized access to WoT assets or affect WoT system in any form | Local physical access, privileged access |
Careless OEM | In order to reduce production costs substitutes security validated original HW parts with low quality unvalidated replacement parts potentially impacting security. | Local physical access, privileged access |
Careless
|
In order to reduce solution deployment costs utilizes low quality SW, performs poor testing, misconfigures hardware or software, TDs and/or access control policies. | Local physical access, privileged access |
Non-WoT End Point Attacker | Tries to get authorized access/modify any asset stored at non-WoT end points (Cloud, non-WoT devices etc.) Reasons: monetary, fame etc. | Remote or local attack |
In
order
to
correctly
define
WoT
attack
surfaces
one
needs
to
determine
the
system's
trust
model
as
well
as
execution
context
boundaries.
Figure
1
WoT
High-Level
Architecture
Security
View
presents
a
A
high-level
view
of
the
WoT
architecture
from
the
security
point
of
view,
view
is
presented
in
Figure
2
,
showing
all
possible
execution
boundaries.
However,
in
practice
certain
execution
boundaries
might
not
be
present
as
they
are
dependent
on
the
actual
device
implementation.
The main execution boundaries for WoT system are:
Boundary | Description | Notes |
---|---|---|
Script Execution Boundary | Separates execution contexts between different Thing Instances. If present, this boundary should be implemented either as having different script runtime contexts (with WoT runtime isolation means) or by having separate process execution contexts (with OS process isolation means) |
This
boundary
is
required
if
we
assume
that
WoT
Runtime
can
run
untrusted
scripts
or
if
some
scripts
|
WoT Runtime Instance Execution Boundary |
Separates
execution
contexts
between
different
WoT
Runtime
instances.
If
present,
this
boundary
should
be
implemented
using
at
least
with
OS
process
|
This
boundary
is
required
if
we
assume
that
we
have
different
|
WoT Execution Boundary |
Separates
execution
contexts
between
WoT
runtime
(including
WoT
Protocol
Bindings)
and
the
rest
of
the
system.
If
present,
this
boundary
should
be
implemented
at
least
|
This boundary is required if we assume that WoT Runtime might run untrusted scripts or there might be untrusted Protocol Bindings present. It is also required if a device also runs a non-WoT SW stack and elements of that stack can potentially be compromised |
WoT Runtime and Protocol Bindings Execution Boundaries |
Separate
execution
contexts
between
WoT
runtime
and
Protocol
Bindings.
If
present,
these
boundaries
should
be
implemented
at
least
|
These boundaries might be needed if we assume that a WoT Runtime can run untrusted scripts and would like to implement additional access control measures at the Protocol Binding level. |
The following WoT attack surfaces are always in-scope for the WoT Security model:
System Element | Compromise Type(s) | Assets Exposed | Attack Method |
---|---|---|---|
WoT Interface | Modification or unauthorized access to any affected asset, Unauthorized execution of exposed WoT Interfaces, Denial of Service |
TDs
,
|
Network attack |
WoT Protocol Bindings | Modification or unauthorized access to any affected asset, Unauthorized execution of exposed WoT Protocol Bindings, Denial of Service |
|
Network attack |
The
following
WoT
attack
surfaces
are
only
in-scope
for
the
WoT
Security
security
model
if
we
assume
a
WoT
runtime
can
run
untrusted
scripts
or
we
assume
co-existence
of
different
Thing
providers
System
Providers
(tenants)
on
a
single
physical
device:
System Element | Compromise Type(s) | Assets Exposed | Attack Method |
---|---|---|---|
Script Execution Boundary | Modification or unauthorized access to any asset available to other scripts. Denial of Service |
TDs
,
|
Local attack by an untrusted WoT script using WoT Scripting API or any native OS local method. |
WoT Runtime Instance Execution Boundary |
Modification
or
unauthorized
access
to
any
asset
available
to
|
TDs
,
|
Local attack by an untrusted WoT runtime using any native OS local method. |
If a WoT system allows dynamic installation of scripts inside WoT runtime, the following attack surfaces are added:
System Element | Compromise Type(s) | Assets exposed | Attack Method |
---|---|---|---|
WoT Script Management Interface | Compromise of WoT scripts, including installing an older version of legitimate scripts (rollback) |
|
Network attack |
The following attack surfaces are currently out-of-scope for the WoT Security model:
System Element | Compromise Type(s) | Assets Exposed | Attack Method | Reasoning |
---|---|---|---|---|
WoT Thing Directory | Modification or unauthorized access to hosted TDs, Denial of Service by preventing legitimate users from obtaining TDs, Inference of non-public or privacy sensitive information based on the observation of the protocol between the WoT endpoints and Things Directory. | TDs , history of interaction with Thing Directory | Any remote or local attack method on a Thing Directory service that results in attacker obtaining unauthorized access or the ability to modify TDs hosted by this service or to cause any type of DoS attack on the hosting service itself. In addition public hosting of TDs by a Thing Directory can have strong privacy implications and risks, as well as obtaining information on interactions between the Thing Directory and a given WoT network setup or user | This attack surface is out of scope because WoT specifications do not define the internal structure of Thing Directory services or their interaction protocol. However, 6.4 Secure Practices for Thing Directory Interaction Protocols lists generic recommendations and best known security practices that should be followed when designing Thing Directory services and interaction protocols. |
Non-WoT endpoints |
Component
compromise.
This
includes
legacy
devices,
remote
clouds
and
other
infrastructures,
user
interfaces
such
as
browsers
or
applications
on
a
smartphone,
etc.)
|
Any
type
of
|
| This attack surface is out of scope because WoT specifications do not cover non-WoT endpoints. |
Native
|
Component
compromise
on
levels
below
WoT
|
Any type of the WoT assets |
| This attack surface is out of scope because WoT specifications do not cover levels below the WoT Runtime. |
This
section
lists
all
basic
WoT
threats,
both
in-scope
and
out-of-scope.
threats
with
the
exception
of
threats
on
the
attack
surfaces
that
we
have
put
out
of
scope
in
the
previous
section.
The
WoT
threat
model
assumes
that
the
WoT
Client
(which
might
reside
on
a
non-WoT
device,
such
as
a
smartphone,
a
PC
browser,
etc.)
communicates
with
a
WoT
network
using
standard
WoT
Interfaces
and
WoT
Protocol
Bindings.
In
order
to
minimize
the
attack
surface,
it
is
strongly
recommended
that
no
other
separate
communication
means
is
provided
for
this
purpose.
This
threat
model
makes
the
assumption
that
this
recommendation
is
followed.
It
is
also
assumed
that
WoT
Protocol
Bindings
are
trusted
and
cannot
come
from
untrusted
parties.
Editor's
note
:
Protocol
Bindings
as
Thing
Provider
Data
We
should
discuss
whether
Protocol
Bindings
should
be
considered
part
of
Thing
Provider
Data.
This
makes
sense
if
the
Thing
Provider
is
the
one
configuring
the
system
capabilities,
including
protocol
bindings.
Note
that
if
this
configuration
is
done
by
the
OEM,
then
they
are
a
Thing
Provider,
but
there
may
be
another
thing
provider
building
on
top
of
the
basic
configuration
provided
installed
by
the
OEM.
untrusted
parties.
Threat | Adversary | Asset | Attack method and pre-conditions |
---|---|---|---|
|
Network Attacker , Malware Developer , Malicious Users | All WoT assets within the same execution boundary |
Pre-conditions:
General
preconditions
for
a
network
attacker
with
access
to
the
WoT
Protocol
Bindings
and/or
WoT
Interface.
In
case
of
Malicious
Authorized
Solution
User
or
Malware
Attack method: Any remote attack method using WoT Interface or directly using protocol binding interfaces with the purpose of compromising protocol binding component and access to all available WoT assets |
WoT Interface Threat - Thing Instance Compromise | Network Attacker , Malware Developer , Malicious Users | All available WoT assets in the same execution boundary | Pre-conditions: Same as for WoT Protocol Binding Threat Attack method : Same as for WoT Protocol Binding Threat with the purpose of compromising a Thing instance. |
WoT Interface Threat - Unauthorized WoT Interface Access |
Network
Attacker
,
Malware
Developer
,
Malicious
Unauthorized
Users
,
Malicious
|
An
asset
exposed
via
a
WoT
Interface:
WoT
controlled
environment
,
|
Pre-conditions:
An
attacker
with
an
access
to
Attack method: Any remote attack method using a WoT Interface with the purpose of obtaining unauthorized access to a WoT asset |
|
Network Attacker , Malware Developer , Malicious Users | WoT Thing Resources , WoT Infrastructure Resources , Infrastructure operability |
Pre-conditions:
General
preconditions
for
an
attacker
with
access
to
Attack method: Any attack method using a WoT Interface in order to cause |
WoT Communication Threat - TD Authenticity |
Network
Attacker
,
Malware
Developer
,
Malicious
Users
,
Malicious
|
TDs authenticity in-transfer |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Any attack method on a |
WoT
Communication
Threat
-
TD
|
Network
Attacker
,
Malware
Developer
,
Malicious
Users
,
Malicious
|
Confidential and privacy-sensitive parts of TDs in-transfer |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Any attack method on TDs in-transfer with the purpose of obtaining unauthorized access to non-public parts of TDs or passively observing public parts of |
WoT
Communication
Threat
-
|
Network
Attacker
,
Malware
developer
,
Malicious
Users
,
Malicious
|
|
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Any attack method on solution data in-transfer with the purpose of its modification, including sequence of received data, its freshness and illegitimate replay |
WoT
Communication
Threat
-
|
Network
Attacker
,
Malware
Developer
,
Malicious
Users
,
Malicious
|
|
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Any attack method on solution data in-transfer with the purpose of obtaining unauthorized access |
WoT Communication Threat - Side Channels |
Network
attacker
,
Malicious
users
,
Malicious
|
WoT Behavior Metrics |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Passive observation of WoT network and messages with the intention to learn behavioral and operational patterns |
Need
We
may
need
to
add
all
threats
related
to
credentials/policy
management
when
we
clarify
depending
on
how
they
are
exposed/stored
within
WoT
runtime
via
scripting.
However,
currently
WoT
scripting
is
(intentionally)
not
able
to
access
or
manage
credentials;
instead
they
must
be
installed
using
a
separate
management
interface
during
the
runtime's
configuration.
If a WoT system allows dynamic installation of scripts inside a WoT runtime, the following threats are added:
Threat | Adversary | Asset | Attack method and pre-conditions |
---|---|---|---|
WoT Script Management Interface Threat - Script installation | Network Attacker , Malware Developer , Malicious Users | Execution inside WoT Runtime (stepping stone to other further local attacks) and all assets within WoT Runtime |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
Attack method: Attacker installs its own script into WoT runtime using a WoT Script Management Interface |
WoT Script Management Interface Threat - WoT Runtime Compromise | Network Attacker , Malware Developer , Malicious Users | Compromise of WoT Runtime itself (stepping stone to other further local attacks) and all assets within WoT Runtime |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
the
WoT
Script
Attack method: Attacker compromises WoT Runtime itself using a WoT Script Management Interface |
WoT Script Management Interface Threat - DoS | Network Attacker , Malware Developer , Malicious Users | WoT Thing Resources , WoT Infrastructure Resources |
Pre-conditions:
General
preconditions
for
network
attacker
with
access
to
the
WoT
Script
Attack method: Attacker misuses WoT Script Management Interface to cause DoS on things or infrastructure, including |
The general term WoT Script Management Interface Threat may be used to refer to any or all of WoT Script Management Interface Threat - Script installation , WoT Script Management Interface Threat - WoT Runtime Compromise , or WoT Script Management Interface Threat - DoS .
If
a
WoT
system
allows
co-existence
of
different
independent
thing
providers
System
Providers
(tenants)
on
a
single
physical
device
or
if
WoT
scripts
are
assumed
to
be
untrusted,
it
brings
the
following
new
threats
appear
in
addition
to
the
above
ones:
Threat | Adversary | Asset | Attack method and pre-conditions |
---|---|---|---|
WoT Untrusted Script Threat - Script Compromise |
Malicious
|
Component compromise and all WoT assets within the same execution boundary |
Pre-conditions:
An
attacker
has
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker compromising that script and getting controls over it |
WoT Untrusted Script Threat - Runtime Compromise |
Malicious
|
Component compromise and all WoT assets within the same execution boundary |
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on WoT runtime itself with the intent of elevating its privileges to WoT runtime level |
WoT Untrusted Script Threat - Confidentiality |
Malicious
|
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker obtaining knowledge about a script or its configuration |
WoT Untrusted Script Threat - Authenticity |
Malicious
|
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in allowing an attacker |
WoT
Untrusted
Script
Threat
-
TD
|
Malicious
|
TDs
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker obtaining unauthorized access to non-public parts of TDs or privacy sensitive parts of TDs . |
WoT Untrusted Script Threat - TD Authenticity |
Malicious
|
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker achieving unauthorized modification of |
WoT
Untrusted
Script
Threat
-
|
Malicious
|
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker in being able to modify |
WoT
Untrusted
Script
Threat
-
|
Malicious
|
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method on another script running in the same WoT runtime that results in an attacker getting unauthorized access to |
WoT Untrusted Script Threat - DoS |
Malicious
|
WoT
Thing
Resources
,
WoT
Infrastructure
Resources
of
another
|
Pre-conditions:
Same
as
for
WoT
Untrusted
Script
Threat
-
Script
Compromise
Attack method: Any local attack method with the goal of consuming things or infrastructure resources that disturb legitimate operation of co-existing |
Practical
examples
of
Here
we
describe
some
typical
high-level
WoT
scenarios
and
their
security
objectives
are
given
here.
give
practical
examples
of
the
above
threats
for
each
scenario.
In
this
scenario
we
assume
a
standard
home
environment
with
a
WoT
network
running
behind
a
firewall
NAT
that
separates
it
from
the
rest
of
the
Internet.
However
the
WoT
network
is
shared
with
the
standard
user
home
network
that
contains
other
non-WoT
devices
that
have
high
chances
of
being
compromised.
This
results
on
in
viewing
these
non-WoT
devices
as
possible
network
attackers
with
access
to
the
WoT
network
and
its
APIs/Protocol
Bindings.
Other
assumptions:
WoT
scripts
and
protocol
bindings
are
considered
trusted,
trusted;
a
single
solution
provider
System
Provider
exists
on
physical
WoT
devices,
devices;
and
no
dynamic
installation
of
WoT
scripts
are
is
possible.
This
In
this
scenario
implies
the
following
WoT
Security
objectives
:
Threats
are
possible:
Threat name | Example(s) |
---|---|
WoT Protocol Binding Threat |
A
compromised
application
on
a
user
smartphone
connected
to
the
same
internal
network
as
WoT
devices
sends
a
malformed
request
to
a
WoT
device
|
WoT Interface Threat - Thing Instance Compromise |
A
compromised
application
on
a
user
smartphone
connected
to
the
same
internal
network
as
WoT
devices
sends
a
malformed
request
to
a
WoT
device
using
the
WoT
interface.
This
malformed
request
causes
the
respective
Thing
Instance
to
be
compromised
and
attacker
is
able
to
run
|
WoT Interface Threat - Unauthorized WoT Interface Access |
A
user's
party
guest
with
|
WoT Communication Threat - TD Authenticity |
A
compromised
application
on
a
user
smartphone
connected
to
the
same
internal
network
as
WoT
devices
listens
to
the
network
and
intercepts
a
legitimate
TD
|
WoT
Communication
Threat
-
TD
|
A
user's
party
guest
with
|
WoT
Communication
Threat
-
|
A
user's
party
guest
with
Another attack example is a replay of a legitimate WoT interface request to set a setting, for example, increase temperature of the house by a number of degrees. When repeated many times, it might not only make living environment unusable, but also Another attack involves replaying an old legitimate WoT interface request that attacker intercepts while visiting the user's home, such as |
WoT
Communication
Threat
-
|
A
user's
party
guest
with
|
WoT DoS Threat |
A
compromised
application
on
a
user
smartphone
connected
to
the
same
internal
network
as
WoT
devices
sends
huge
amount
of
requests
to
either
a
single
WoT
device
or
all
device
available
in
the
WoT
network
using
directly
Protocol
Bindings
interface
or
WoT
interface.
These
requests
|
WoT
|
|
In
this
scenario
we
assume
an
office
building
environment
that
is
shared
between
a
number
of
independent
companies
(tenants)
with
a
shared
WoT
network
running
that
controls
temperature,
lights,
video
surveillance,
air
etc.
Editor's
note
:
Fill
The
companies
sharing
the
premises
do
not
trust
each
other
and
can
be
viewed
as
potential
attackers.
However,
we
assume
that
there
is
a
trusted
non-compromised
System
Provider
that
sets
the
WoT
network
through
the
whole
building
and
handles
the
on-boarding
and
termination
process
for
all
building
tenants
(making
sure
that
after
company
leaves
the
building,
all
its
data
is
not
present
in
the
content
This
subsection
content
needs
WoT
system
anymore).
Compared
to
Scenario
1
above,
the
main
challenge
here
is
to
securely
share
the
WoT
network
between
these
companies
and
make
sure
their
WoT
System
User
Data
(that
can
include
highly
confidential
company
information)
is
not
exposed,
tampered
with,
etc.
Additionally
one
has
to
take
into
account
the
fact
that
a
set
of
building
tenants
might
change
from
time
to
time,
including
employee
turnover
in
each
company.
Therefore
the
WoT
setup
must
be
added.
flexible
enough
to
start
and
terminate
access
to
the
WoT
system
promptly
to
both
companies
(entire
sets
of
users)
and
individuals.
Privacy
is
also
important
here,
because
companies
need
to
make
sure
that
the
data
about
their
employees
or
clients
is
well
protected,
including
such
information
as
employee
presence.
Since
we
assume
the
presence
of
a
trusted
System
Provider
,
we
can
consider
the
WoT
scripts
and
protocol
bindings
to
be
trusted
also.
Similar
to
Scenario
1,
there
is
only
a
single
System
Provider
present
on
physical
WoT
devices,
and
no
dynamic
installation
of
WoT
scripts
are
possible
for
simplicity.
This
In
this
scenario
implies
the
following
WoT
Security
objectives
:
Threats
are
possible:
Threat name | Example(s) |
---|---|
WoT Protocol Binding Threat |
|
WoT Interface Threat - Thing Instance Compromise |
|
WoT Interface Threat - Unauthorized WoT Interface Access |
|
WoT Communication Threat - TD Authenticity |
|
WoT
Communication
Threat
-
TD
|
|
WoT
Communication
Threat
-
|
|
WoT
Communication
Threat
-
|
|
WoT DoS Threat |
|
WoT Communication Threat - Side Channels |
|
In
this
scenario
we
assume
an
industrial
factory
or
infrastructure
(power
plant,
water
distribution
system)
system,
etc.)
environment
that
is
using
WoT
network
to
monitor
or
perform
certain
automation
tasks.
tasks
in
its
Operational
Technology
(OT)
network.
Compared
to
other
scenarios
above,
the
main
challenge
here
is
to
guarantee
safety
and
availability
of
the
critical
infrastructure.
Therefore,
for
example,
Denial-Of-Service
attacks
must
be
mitigated
as
well
as
possible.
On
the
other
hand,
privacy
is
usually
less
important
for
this
scenario.
Similar to the previous scenarios, we assume that there is a trusted non-compromised System Provider that sets up the WoT network, so we can consider all WoT scripts and protocol bindings to be trusted also. We also assume there is only a single System Provider present on physical WoT devices and a single tenant on all system, and assume no dynamic installation of WoT scripts is possible for simplicity.
Due to the high safety and availability requirements in the industrial environment, typically the WoT network (part of a bigger OT network) won't be shared with other tenants of the same building and normally won't be shared with the general IT network of the same company. The IT network is where all other company operations are happening, for example, accounting. We also don't expect factory employees to browse the internet in the coffee break using the OT network (and ideally not the IT network; in some companies, a third network is even provided for employee personal use or for less-trusted personal devices.) However, usually some bridging must be present between the OT and IT networking in order to support monitoring requirements, so these networks are not fully isolated. In this scenario, the risk of compromised devices and applications interacting with the WoT network is limited but nonetheless present. Therefore the usual WoT threats, described in the previous scenarios, still apply, if a malicious application or device gets into the industrial OT WoT network.
Also, a factory employee with authorized access to the OT WoT network can be also viewed as a potential attacker. The additional security challenge in this case is role management, i.e. distribution of authorized accesses between the actors (factory employees, devices with actuators, etc.) in such a way that a single misbehaving actor does not have enough authorization to endanger the safety and availability of the whole infrastructure. Similar to the case in Scenario 2, the ability to promptly terminate an employees’ access rights to the WoT network when necessary, and without disrupting other activities, is essential.
In
this
section
we
focus
specifically
on
the
content
privacy
aspects
that
are
important
to
keep
in
mind
while
developing
and
deploying
WoT
solutions.
The
threat
model,
described
in
3.2
Threat
Model
This
subsection
content
needs
to
be
added.
,
already
takes
into
account
numerous
privacy-related
threats
and
aspects.
However,
this
section
summarizes
them
and
gives
guidelines
and
recommendations
specifically
aimed
at
minimizing
privacy-related
risks.
This
scenario
implies
the
The
following
WoT
Security
objectives
:
privacy
threats
can
potentially
affect
the
privacy
of
WoT
system
users
:
|
|
Mitigation |
---|---|---|
Disclosing
WoT
|
|
WoT
|
|
|
The
communication
between
WoT
|
Leaking
WoT
|
|
WoT
|
Tracking
WoT
|
|
|
This
subsection
content
needs
We
may
need
to
be
added.
Here
we
will
list
the
criteria
that
raise
risk
level
for
particular
WoT
architecture,
such
as
handing
privacy-sensitive
data,
physical
safety,
etc.
Also
talk
about
capabilities
of
devices
themselves,
what
security
protocols
are
supported,
how
processes
isolation
is
implemented
(granularity:
everything
runs
mention
privacy
risks
associated
with
links.
In
particular,
dereferencing
links
carries
similar
inferencing
risks
as
one
process,
only
kernel
-
vs.
userspace
isolation,
process
isolation,
script
isolation
etc.),
etc.
Need
also
to
list
additional
factors
that
are
important
in
selecting
security
architecture.
context
file
dereferencing.
Best
practices
in
security
are
constantly
evolving,
and
it
is
important
to
keep
up
to
date.
At
the
same
time,
IoT
is
new
enough
and
is
itself
evolving
rapidly
enough
that
best
practices
are
just
now
emerging
and
are
likely
to
require
rapid
updating.
Recently
attempts
have
been
made
to
document
and
categorize
useful
approaches
to
security
in
IoT.
The
following
are
among
some
of
the
more
useful
references.
points
of
reference:
Here are some additional general references for threat modeling and security architecture planning. These frameworks can be helpful when designing the security architecture of a specific IoT system or standard. OWASP in particular is useful for Things using the HTTP protocol for their network interface.
The following documents define the security and privacy considerations that should be included in internet standards. These references helped define the topics covered in this document.
The references below are relevant, but the text should explain them more, categorize them, and put them in context. Also, we don't necessarily need all of these, and may need others not listed.
Additional references:
Should use references from global ReSpec bibliography whenever possible, rather than local bibliographic entries.
Based
on
the
security
assets
main
WoT
assets,
privacy
and
security
threats
listed
above,
in
3.2.2
Assets
,
3.2.5
Threats
and
4.
Privacy
Considerations
,
we
provide
here
a
set
of
recommended
practices
for
enhancing
security
and
privacy
when
designing
various
aspects
of
a
WoT
network.
Depending
on
the
usage
scenario,
these
may
not
be
adequate
for
securing
any
given
WoT
system,
however.
The
full
threat
model
should
be
considered
to
identify
and
mitigate
any
additional
threats
for
a
specific
WoT
system.
Secure
Delivery
and
Storage
of
Thing
Description
Description.
When
a
TD
is
transferred
between
WoT
endpoints,
to
or
from
the
TD
hosting
service,
it
is
important
to
at
least
use
secure
protocols
guaranteeing
data
authenticity
authenticity,
freshness
and
in
many
cases
confidentiality
(depending
on
whenever
a
TD
contains
any
confidential
information)
or
privacy-sensitive
information).
TDs
should
not
be
provided
without
first
authenticating
the
requester
and
checking
that
they
have
authorization
to
avoid
manipulation
of
a
TD.
access
the
requested
TDs.
If
end-to-end
TD
authenticity
or
confidentiality
is
required,
it
is
possible
to
sign
TD
objects
with
either
digital
signatures
(using
asymmetric
cryptographic
primitives)
or
Message
Authentication
Codes
(MACs,
using
symmetric
cryptographic
primitives).
Such
digital
signatures
or
MACs
are
created
by
the
producers/issuers
of
TD
objects
and
validated
by
consumers
of
TD
objects
(which
should
reject
signed
TD
objects
whose
signatures/MACs
are
invalid).
For
TD
objects
expressed
in
JSON,
RFC
7515
(IETF
JSON
Web
Signature:
https://datatracker.ietf.org/doc/rfc7515/)
provides
guidelines
see
6.5
Secure
Practices
for
computation
and
validation
of
digital
signatures
or
MACs
using
JSON-based
data
structures.
Similarly,
if
end-to-end
TD
confidentiality
is
required
(though
probably
a
much
more
rare
case
than
authenticity),
it
is
possible
to
encrypt
TD
objects
using
available
cryptographic
encryption
primitives.
For
TD
objects
expressed
in
JSON,
RFC
7516
(IETF
JSON
Web
Encryption:
https://datatracker.ietf.org/doc/rfc7516/)
provides
the
guidelines
security
for
encryption
and
decryption
of
JSON-based
data
structures.
more
specific
guidance.
When
a
TD
is
stored
at
the
end
device
device,
in
a
gateway
(e.g.
in
a
cache
or
directory
service)
or
in
remote
storage,
storage
(e.g.
an
archive),
its
authenticity
and
in
some
cases
confidentiality
should
also
be
protected
using
the
best
available
local
methods.
An
access
control
mechanism
This recommendation helps prevent the following threats: WoT Communication Threat - TD Authenticity , WoT Communication Threat - TD Confidentiality and Privacy , Disclosing WoT Thing/Device configuration , Disclosing WoT System configuration , Tracking WoT System User .
Avoid Exposing Persistent Unique Identifiers
When
defining
fields
exposed
by
a
TD
immutable
information
should
also
be
used
avoided,
especially
if
that
prevents
illegitimate
modification
of
information
can
be
tied
to
a
particular
person
or
is
associated
with
personally
identifiable
information.
It
is
specifically
strongly
recommended
to
avoid
exposing
any
immutable
hardware
identifiers.
Instead
it
is
recommended
to
use
"soft
identifiers",
i.e.
identifiers
that
can
be
changed
at
some
point
during
the
device's
lifecycle.
Given
the
requirements
of
Linked
Data,
it
may
not
be
possible
to
change
the
TD's
parts.
identifier
during
the
Operational
state
of
a
device
without
additional
infrastructure
to
register
consumers
of
a
TD
and
notify
them
of
updates,
but
it
should
at
least
be
possible
during
(re-)provisioning.
This
recommendation
helps
prevent
the
following
threats:
WoT
Communication
Threat
-
TD
Authenticity
Confidentiality
and
Privacy
,
Disclosing
WoT
System
configuration
,
Tracking
WoT
System
User
.
Minimize Publicly Exposed Information in TD
WoT TDs should minimize the amount of information that is publicly available about a WoT Thing. For example, the TD should generally not identify the version of the software or operating system a device is running, since this information can be used to identify vulnerable systems. Instead the TD should capture all information needed to support interoperability without reference to particular implementations.
This
recommendation
helps
prevent
the
following
threats:
WoT
Communication
Threat
-
TD
Confidentiality/Privacy
Confidentiality
and
Privacy
,
Disclosing
WoT
Thing/Device
configuration
,
Disclosing
WoT
System
configuration
,
Tracking
WoT
System
User
,
WoT
DoS
Threat
.
Limit TDs exposure
Limit clients who can obtain a certain TD (or its privacy-sensitive parts) via authentication and authorization methods. This can be done by exposing a number of TD variants for the same WoT Thing based on the level of client’s access. For example, versions of a TD for "public access" may be generated with a subset of information in the full TD, omitting (for example) support or version metadata.
This
recommendation
helps
prevent
the
following
threats:
WoT
Communication
Threat
-
Local
Storage
TD
Confidentiality
and
Privacy
,
Disclosing
WoT
Thing/Device
configuration
,
Tracking
WoT
System
User
,
WoT
DoS
Threat
.
Use Secure Transports
When
defining
protocols
for
APIs
exposed
by
a
TD,
it
is
often
important
to
use
secure
protocols
guaranteeing
data
System
User
Data
authenticity
and
confidentiality.
Specifically,
HTTPS
(using
TLS),
CoAPS
(using
DTLS),
and
MQTTS
(using
TLS)
should
be
used
if
any
kind
of
authentication
or
secure
access
is
required.
If
data
travels
many
intermediate
nodes
(potentially
malicious
or
not
privacy-preserving),
end-to-end
encryption
methods
should
be
preferred.
This
recommendation
helps
prevent
the
following
threats:
WoT
Communication
Threat
-
Thing
System
User
Data
Authenticity
,
WoT
Communication
Threat
-
Thing
System
User
Data
Confidentiality
and
Privacy
,
Leaking
WoT
System
User
Data
.
User Consent
Keep System Users informed about the information that can be exposed or collected about them. Provide a way for System Users to control the degree of such exposure.
This recommendation helps prevent the following threats: WoT Communication Threat - System User Data Confidentiality and Privacy , Leaking WoT System User Data .
Use Appropriate Access Control Schemes
Use Security Metadata options to configure appropriate authentication and authorization methods for WoT Interfaces exposed by a WoT Thing. Minimize the amount of WoT Interfaces without any access control defined (including emitting public events). Consider different levels of access for different users.
This recommendation helps prevent the following threats: WoT Interface Threat - Unauthorized WoT Interface Access , WoT Interface Threat - Thing Instance Compromise , WoT Communication Threat - System User Data Authenticity , WoT Communication Threat - System User Data Confidentiality and Privacy , Leaking WoT System User Data , Disclosing WoT Thing/Device configuration , WoT DoS Threat .
Avoid Heavy Functional Processing without Authentication
When defining WoT Interfaces exposed by a TD, it is important to avoid any heavy functional processing before the successful authentication of a WoT client. Any publicly exposed network interface should avoid heavy processing altogether.
This recommendation helps prevent the following threats: WoT DoS Threat .
When
defining
fields
exposed
by
a
TD
personally
identifiable
information
should
be
avoided.
It
is
also
strongly
recommended
to
avoid
exposing
any
immutable
hardware
identifiers.
Instead
it
is
recommended
to
use
"soft
identifiers",
i.e.
identifiers
that
can
be
changed
during
device
lifecycle.
This
recommendation
helps
prevent
the
following
threats:
WoT
Communication
Threat
-
TD
Confidentiality/Privacy
.
4.1.5
Minimize
Network
Interface
Functionality
and
Complexity
Network
interfaces
exposed
by
a
TD
(WoT
Interfaces)
should
only
provide
the
minimal
necessary
functionality,
which
helps
to
minimize
implementation
errors,
possibilities
for
exposing
potentially
sensitive
data,
DoS
attack
possibilities
etc.
Devices
should
be
strongly
encapsulated,
meaning
the
network
interfaces
should
not
expose
implementation
details
(for
example,
the
use
of
particular
software
frameworks).
Consider
different
levels
This recommendation helps prevent the following threats: WoT Interface Threat - Thing Instance Compromise , WoT Interface Threat - Unauthorized WoT Interface Access , WoT DoS Threat .
Strong Validation and Fuzz Testing on All WoT Interfaces
All
WoT
Interfaces
(and
especially
public
ones)
should
be
well-tested
(including
fuzz
testing)
and
validated
since
they
are
a
primary
attack
surface
of
access
for
different
users.
a
WoT
Thing.
This recommendation helps prevent the following threats: WoT Interface Threat - Thing Instance Compromise , WoT Interface Threat - Unauthorized WoT Interface Access , WoT DoS Threat .
This subsection content needs to be added.
If end-to-end authenticity is desired, it is possible to sign WoT objects (TDs, System User Data ) with either digital signatures (using asymmetric cryptographic primitives) or Message Authentication Codes (MACs, using symmetric cryptographic primitives). Such digital signatures or MACs are created by the producers/issuers of the objects and validated by consumers of the objects (which should reject signed the objects whose signatures/MACs are invalid). For data expressed in JSON, RFC 7515 (IETF JSON Web Signature) provides guidelines for computation and validation of digital signatures or MACs using JSON-based data structures.
Similarly, if end-to-end confidentiality is desired, it is possible to encrypt objects using available cryptographic encryption primitives. For the objects expressed in JSON, RFC 7516 (IETF JSON Web Encryption) provides guidelines for encryption and decryption of JSON-based data structures.
This recommendation helps prevent the following threats: WoT Communication Threat - System User Data Authenticity , WoT Communication Threat - System User Data Confidentiality and Privacy , Leaking WoT System User Data , WoT Communication Threat - TD Authenticity , WoT Communication Threat - TD Confidentiality and Privacy .
The
WoT
is
intended
to
be
used
in
variety
of
use
cases
and
deployment
configurations.
While
the
below
list
does
examples
in
this
section
do
not
cover
all
possible
deployment
variations,
it
covers
the
most
they
cover
many
common
cases
and
cases,
shows
the
ways
how
security
mechanisms
can
be
configured
for
them,
as
well
as
brings
attention
to
the
these
cases,
and
highlights
some
details
relevant
details.
to
security.
Figure
2
Basic
WoT
Thing
and
WoT
Client
3
shows
the
basic
WoT
Client
(can
(which
can
be
a
browser
or
an
application
on
a
user
user's
smartphone)
that
is
used
to
directly
operate
the
a
WoT
Thing
(Garage
door
controller
or
other
HW
device).
Thing.
The
latter
WoT
Thing
exposes
a
WoT
network
interface
and
also
directly
provides
a
Thing
Description.
The
Thing
Description
with
actions
describes
the
interactions
that
can
be
performed
on
a
the
WoT
Thing.
From
a
security
point
of
view
two
aspects
are
important
to
consider
in
this
scenario.
First
First,
the
WoT
Client
should
be
certain
that
it
is
talking
to
the
correct
WoT
Thing
and
not
to
some
arbitrary
other
device
exposed
in
the
WoT
network.
I.e.
user
performing
controls
on
the
same
network.
Users
intending
to
control
a
specific
device,
for
example
opening
a
garage
door
wants
door,
want
to
make
sure
it
is
they
are
talking
to
his
or
her
their
own
garage
door
device.
In
security
terms
it
this
means
that
WoT
Client
must
have
a
way
to
authenticate
the
device
exposing
the
WoT
Thing.
Second,
upon
receiving
any
requests
from
a
WoT
Client,
the
WoT
Thing
must
verify
the
the
WoT
Client
is
authorized
to
perform
such
requests.
I.e.
For
example,
a
garage
door
must
only
process
"open"
requests
from
devices
associated
with
user
authorized
users
or
service
provider
providers
and
not
from
arbitrary
guests
in
the
house.
passerby.
Both
aspects
These
requirements
can
both
be
fulfilled
using
a
variety
of
different
security
mechanisms
and
the
end
decision
on
a
mechanisms.
The
choice
of
concrete
method
security
mechanisms
depends
on
the
deployment
scenario,
as
well
as
capabilities
of
involved
the
devices.
The
Either
or
both
the
WoT
Client
is
not
expected
be
a
resource
limited
device,
but
the
device
exposing
and
the
WoT
Thing
might
have
some
resource
constraints.
resource,
network
connectivity,
or
user
interface
constraints
that
may
limit
the
choice
of
security
mechanisms.
For example, suppose the WoT Thing is actually an OCF device that has been provided with a Thing Description. This is a reasonable use case since WoT metadata can be used to describe OCF devices, which have RESTful CoAP and/or HTTP network interfaces. Since the WoT only describes devices during operational phase, and does not describe onboarding or provisioning processes, we have to refer to an external standard (such as OCF) that does specify these processes. However, it should be clear that much of what is described in this example is applicable to other standards or even to custom solutions.
The
WoT
Client
and
the
OCF
device
exposing
providing
the
network
interface
acting
as
the
WoT
thing
Thing
can
use
one
of
the
following
methods
recommended
by
the
OCF
Security
Specification
[
Ocf17
]
(see
Section
10)
to
mutually
authenticate
each
other
given
that
there
is
a
way
to
supply
credential
information
required
for
authentication
during
the
WoT
network
setup/provisioning
stage:
provisioning:
In
case
it
is
not
possible
to
pre-provision
any
of
the
types
of
credentials
described
above
during
the
WoT
network
setup
phase
or
if
the
WoT
Thing
wants
to
create
use
a
more
fine-grained
access
control
policy
on
the
WoT
network
interfaces
its
it
is
exposing
(different
(for
example,
different
controls
might
require
different
levels
of
authorization),
the
following
methods
can
be
used
instead:
Instead
of
assigning
different
access
tokens
to
different
WoT
Interfaces,
it
is
also
possible
to
group
the
related
WoT
Interfaces
under
some
group
or
capability
name
(i.e.
"Light
controls",
"House
access"
etc.)
and
assign
one
token
per
group
to
guard
any
of
such
interfaces.
This
might
can
provide
a
well-balanced
more
balanced
access
control
granularity.
granularity
in
many
circumstances.
The
suitable
choice
Suitable
choices
of
the
above
security
measures
allows
to
mitigate
mitigation
of
the
WoT
Interface
Threat
-
Unauthorized
WoT
Interface
Access
threat.
In
addition
to
above
measures
the
above
measures,
authenticity,
confidentiality
and
replay
protection
of
transferred
solution
data
and
of
TDs
between
the
WoT
Client
and
the
WoT
Thing
is
strongly
recommended
for
the
scenarios
where
an
attacker
can
observe
or/and
modify
the
traffic
in
the
WoT
network.
While
TD
transfer
might
only
require
the
authenticity,
authenticity
protection,
the
solution
data
itself
usually
requires
all
protection
of
the
properties.
all
its
aspects.
This
helps
to
mitigate
the
following
threats:
WoT
Communication
Threat
-
TD
Authenticity
,
WoT
Communication
Threat
-
TD
Confidentiality/Privacy
Confidentiality
and
Privacy
,
WoT
Communication
Threat
-
Thing
System
User
Data
Authenticity
,
WoT
Communication
Threat
-
Thing
System
User
Data
Confidentiality
and
Privacy
.
The
authenticity,
Authenticity,
confidentiality
and
replay
protection
can
be
guaranteed
by
underlying
usage
of
secure
transport
protocols
to
exchange
the
data
between
the
WoT
client
Client
and
the
WoT
Thing,
such
as
TLS/DTLS.
If
the
underlying
protocol
does
not
provide
the
required
security
measures
(such
as
plain
COAP
CoAP
run
over
non-TLS
a
non-(D)TLS
protected
channel),
then
authenticity
and
confidentiality
of
the
transferred
data
can
be
implemented
separately
on
the
application
layer.
The
recommended
method
for
doing
this
in
resource
constrained
environments
is
to
use
the
Object
Security
of
CoAP
(OSCOAP)
(OSCoAP)
method
described
in
the
IETF
Object
Security
of
CoAP
(OSCOAP)
(OSCoAP)
specification
draft
[
OSCOAP17
].
The
scenario
shown
in
Figure
3
Basic
WoT
Thing
and
WoT
Client
with
TD
provided
from
Things
Directory
4
is
identical
similar
but
with
an
the
important
difference
that
a
Thing
description
is
not
stored
on
a
the
WoT
Thing
device,
but
device
nor
returned
by
it
directly.
The
TD
is
instead
provided
to
the
WoT
client
from
Things
a
Thing
Directory
residing
on
some
other
system,
such
as
a
remote
cloud.
cloud
server.
This
mode
may
be
useful
for
"retro-fitting"
existing
devices
with
Thing
Descriptions,
for
example,
or
when
more
secure
access
to
the
TD
is
required
than
the
device
itself
can
support.
The
primary
additional
security
consideration
of
this
scenario
is
a
the
need
for
the
secure
transfer
of
the
TD
between
the
WoT
Client
and
Things
the
Thing
Directory.
The
Thing
Directory
that
can
reside
in
a
gateway
but
could
also
be
supported
by
a
service
running
on
a
remote
cloud
or
other
remote
location.
Similarly
to
the
methods
described
above
such
transfer
should
be
done
using
underlying
secure
transport
protocols.
Since
we
do
not
expect
In
the
case
that
the
WoT
Client
to
be
is
not
resource
constrained,
the
usage
of
TLS/DTLS
is
the
recommended
method.
In
case
the
remote
cloud
does
not
guarantee
the
secure
storage
and
delivery
of
Thing
Descriptions
to
the
WoT
Client
or
in
case
the
remote
cloud
is
not
a
trusted
entity,
the
authenticity
of
the
Thing
Description
should
be
verified
using
other
methods
on
the
application
layer,
such
as
wrapping
the
Thing
Description
into
a
protected
CBOR
Object
Encryption
and
Signing
(COSE)
object
[
COSE17
]
].
This
can
be
done
by
the
provider
of
the
Thing
Description
and
verified
by
the
WoT
Client
upon
after
the
download
from
the
remote
cloud.
A
Figure
5
,
as
in
the
Figure
4
WoT
Thing
and
WoT
Client
via
Gateway
3
shows
the
same
basic
configuration,
also
allows
a
WoT
Client
that
is
used
to
connect
to
and
operate
the
or
monitor
a
WoT
Thing.
However
in
contrast
to
the
previous
basic
(direct
connection)
case,
the
interaction
between
the
WoT
Client
and
the
WoT
Thing
happens
via
the
is
now
mediated
by
a
WoT
Servient
Gateway.
The
latter
WoT
Servient
Gateway
exposes
a
WoT
interface
and
provides
a
Thing
Description
with
actions
that
can
be
performed
on
a
describes
interactions
that
that
apply
to
the
Thing.
In
general,
the
TD
provided
by
the
WoT
Servient
Gateway
is
structurally
identical
to
the
one
that
would
have
been
provided
by
the
Thing
directly,
except
for
any
necessary
modifications
to
URLs,
protocols
used,
and
(perhaps)
a
modified
security
configuration.
From
a
security
standpoint
this
case
is
quite
similar
to
the
one
described
in
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
with
the
.
The
main
difference
is
that
mutual
authentication
should
be
established
between
all
directly
communicating
parties,
i.e.
between
the
WoT
Client
and
the
WoT
Servient
Gateway,
and
as
well
as
between
the
WoT
Servient
Gateway
and
the
device
exposing
the
WoT
Thing.
Thing
network
interface.
If
there
is
no
direct
communication
between
the
WoT
Servient
Gateway
and
the
device
providing
the
WoT
Thing
however
the
mutual
authentication
between
them
is
redundant.
The
authentication
mechanisms
described
in
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
are
also
applicable
for
this
case.
The
Thing
Description
that
the
WoT
Servient
Gateway
device
provides
to
the
WoT
Client
can
be
the
same
as
it
gets
from
the
device
exposing
the
WoT
Thing
or
it
can
be
modified
to
better
suit
the
deployment
use
case
or
expose
additional
functionality
via
the
WoT
Gateway.
It
is
also
possible
that
the
end
device
behind
the
WoT
Gateway
is
a
non-WoT
device
and
does
not
provide
any
Thing
Description
on
its
own,
neither
supports
and
may
not
support
any
interaction
via
the
WoT
a
WoT-compatible
network
Interface.
In
this
case
the
WoT
Servient
Gateway
has
to
build
the
Thing
Description
by
itself
i
and
expose
it
to
the
WoT
Client.
For
all
typical
use
cases,
the
WoT
Servient
Gateway
should
be
considered
as
a
trusted
entity
and
in
this
case
it
can
freely
modify
or
build
Thing
Descriptions
it
exposes
as
well
as
setup
the
set
up
fine-grained
access
controls
on
different
exposed
WoT
Interfaces.
It
The
WoT
Servient
Gateway
can
do
it
this
using
the
same
methods
described
in
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
,
i
and
therefore
act
acts
fully
on
behalf
of
the
end
device.
Figure
5
WoT
Thing
and
WoT
Client
via
Gateway
with
Remote
Cloud
6
is
identical
similar
to
the
previous
case
but
with
an
important
difference
that
difference:
a
Thing
Description
is
not
provided
by
the
the
WoT
Servient
Gateway,
but
can
be
fetched
by
the
WoT
client
from
a
Things
Thing
Directory
residing
on
a
remote
cloud.
system.
Similar
to
the
previous
case,
this
Thing
Description
can
either
be
the
original
Thing
Description
supplied
by
the
end
device
(i.e.
garage
door)
or
modified
by
the
WoT
Servient
Gateway.
Regardless
of
the
actual
setup,
the
transfer
of
a
Thing
Description
between
any
two
endpoints
should
be
done
using
underlying
secure
protocols
and
protocols.
Currently
the
usage
use
of
TLS/DTLS
TLS
or
DTLS
is
the
recommended
method.
recommended.
Similarly
to
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
,
in
case
the
remote
cloud
system
does
not
guarantee
the
secure
storage
and
delivery
of
Thing
Descriptions
to
the
WoT
Client
or
in
case
the
remote
cloud
system
is
not
a
trusted
entity,
the
authenticity
of
the
Thing
Description
should
be
verified
using
other
methods
on
in
the
application
layer.
Figure 7 shows another common situation where the WoT Thing resides in a local protected network, e.g. behind a NAT/Firewall. In this case the WoT Client cannot contact the WoT Thing directly. In the configuration shown here the communication between the WoT Client and the WoT Thing is handled via a pair of Wot Gateway Servients: one residing in the local protected network, known as the Local Gateway, and another running in the cloud, known as the Remote Gateway. We refer to this configuration as a "Split Proxy" because the combination of the Local and Remote Proxy together act like a single proxy service. The Local and Remote Gateway Servients are connected with a secure channel (which may be non-WoT, e.g., it does not have to use a protocol known to WoT) as the Local Gateway Servient only communicates over this channel with the Remote Gateway Servient. The WoT Remote Gateway Servient should use the mechanisms described in Section 7.1 Basic Interaction between WoT Thing and WoT Client in order to authenticate and authorize the WoT Client before processing any of its requests. Similar to the configurations described in Section 7.1 Basic Interaction between WoT Thing and WoT Client , secure protocols should be used to protect authenticity and confidentiality and provide replay protection when data is exchanged between the WoT Client and the Remote Gateway Servient. If the WoT Client is authorized, then the Remote Gateway Servient can package the WoT request and transfer it over the secure channel to the Local Gateway Servient, which in turn can issue requests to the WoT Thing on the local network. The local network channel between the Local Gateway Servient and the WoT Thing can be left unprotected (relying purely on the closed nature of the local network), but it is strongly recommended to employ suitable additional security mechanisms as described in Section 7.1 Basic Interaction between WoT Thing and WoT Client to perform authentication and authorization of involved parties (WoT Thing and Local Gateway Servient), as well as to provide confidentiality and integrity of transferred solution data and the TD.
An alternative security setup for this scenario can use end-to-end security authentication and authorization. In this case the WoT Client would not only need to authenticate and authorize itself to the Remote Gateway Servient, but also to the WoT Thing. In this case it would need a separate set of security credentials, required to successfully authenticate with each party. The exposed TD should indicate the mechanisms to obtain these credentials, e.g. via OAuth2.
As an alternative to the use of a split proxy, which requires a trusted remote proxy to accept interaction requests on behalf of the WoT Thing, a secure tunnel (such as an SSH tunnel) can be set up between the WoT Thing and an endpoint in the cloud. In order to traverse the NAT the WoT Thing would have to initiate the connection, so in practice this would be a reverse tunnel set up by the "server". However, then a port made available by the Thing would be made available directly on the cloud server supporting the tunnel endpoint, possibly mapped to a different port. The use of a tunnel for NAT traversal is shown in Figure 8 .
In this configuration the WoT Thing must be responsible for all security, including (if necessary) certificates appropriate for the tunnel endpoint in the cloud. i This implies that the WoT Thing needs to be relatively powerful, as constrained devices may not be able to support security mechanisms suitable for direct exposure on the internet. The WoT Thing would also have to be actively maintained and patched. If the WoT thing provides a TD, it should use URLs that refer to the tunnel endpoint. This generally means that the port used for the local side of the tunnel should not be used to provide local connections as the certificates will be incorrect for local connections. Instead a separate port (and possibly a separate TD with local URLs) should be provided.
One advantage of this arrangement is that communication is never available in plaintext on either the gateway or the client. Specifically, the private keys for end-to-end communication between the WoT Thing and the WoT Client, assuming a secure protocol such as HTTPS is used, never need to be made available to either the local gateway or to the cloud portal. In other words, this configuration supports end-to-end encrypted communication, and does not rely on trusting either the gateway or the cloud portal. Because of this, it is not technically necessary for the tunnel to be over SSH; a regular IP tunnel would suffice.
A variation of this is shown in Figure 9 . A reverse tunnel is still used here, but terminates in a local port "inside" the cloud portal, that is, the local port is not made visible outside the cloud portal's firewall. A local proxy service then runs inside the cloud portal and provides a bridge to a secure external network interface. For example, the protocol from the WoT Thing might be HTTP, which the proxy service could bridge to an external HTTPS network interface. In this case, the tunnel should be encrypted (for example, using SSH) to prevent eavesdropping; a regular IP tunnel is not sufficient. Depending on the configuration, the unencrypted traffic (e.g., HTTP) may also be visible on the local network. In this case, the only protection would be from that provided by the local network, e.g., WPA. If such a relatively unprotected local interface is not desirable, another SSH tunnel can be used between the WoT Thing and the Gateway, or the WoT Thing can act as its own gateway (with the HTTP traffic protected behind a firewall).
To support local SSH tunnels, of course credentials need to be provisioned between the gateway and the cloud portal. However, this only needs to be done once, when the gateway is installed.
It is worth emphasizing that the security in this configuration is weaker than in the end-to-end tunnel configuration. In particular, unencrypted traffic is available both locally (on the local network and/or inside the gateway) and in the cloud portal. Therefore both the gateway and the cloud portal need to be trusted. This can be mitigated somewhat by using application-level end-to-end object security [ COSE17 ].
Yet another variant of this approach is shown in Figure 9 . In this variant, the proxy is extended to support caching. This means that the proxy may not always forward requests to the WoT Thing, but may instead respond on its behalf using stored state.
There are two sub-variants of this approach. First, a simple HTTP Proxy can be used that caches responses from the WoT Thing. For example, property reads might return an exact copy of an earlier cached payload if only a small amount of time (for some configurable value of "small") has elapsed since the last request for that property. However, this approach still requires that the WoT Thing be "always on" and able to respond as a server in case cached content is not available or has expired. It also requires some care on the part of the WoT Thing to mark payloads as cacheable or uncacheable and configure appropriate time-to-live values.
The second sub-variant, shown in Figure 10 , takes advantage of the metadata provided by the Thing Description. Specifically, the Thing Description indicates which interactions are "properties" that can be "observed". The proxy service can "observe" all such properties and maintain copies of their state in the cloud server (it is also possible to do this in the gateway, a sub-variant of this pattern). Then when a request comes in to read a property, it can be read from the stored state. However, the "observe" pattern allows the WoT Thing to send updates on its own schedule, leading to greater power efficiency. In addition, the proxy service can see from the Thing Description which network interface methods are "actions" and need to be sent directly to the WoT Thing. This reduces the need for the WoT Thing to mark interactions as being cacheable or not.
In both of these sub-patterns, object security (that is, encryption and authentication of payloads at the application level) can be used to preserve confidentiality and integrity if necessary [ COSE17 ]. A caching proxy can simply store and return copies of the encrypted data representing the state of "private" properties.
A caching proxy, being a variant of the proxy configuration discussed above, has similar security caveats.
In
previous
examples
we
have
considered
the
Wot
Servient
as
a
black
box
exposing
a
set
of
WoT
Interfaces
and
Thing
Descriptions.
Figure
6
WoT
Servient
Single-Tenant
11
shows
the
WoT
Servient
(for
example
consider
again
a
garage
door
controller
device
or
a
WoT
Gateway)
in
more
details
detail
with
Scripting
API
support
and
a
couple
of
scripts
running
inside
a
WoT
runtime.
For
this
case
we
considered
consider
all
scripts
to
be
trusted
and
provisioned
to
a
the
device
by
a
single
trusted
entity
(for
example
by
a
device
flashing).
the
manufacturer
during
factory
installation).
Since all scripts running inside the WoT runtime are considered trusted for this scenario, there is no strong need to perform strict isolation between each running script instance. However, depending on device capabilities and deployment use case scenario risk level it might be desirable to do so. For example, if one script handles sensitive privacy-related data and well-audited, it might be desirable to separate it from the rest of the script instances to minimize the risk of data exposure in case some other script inside WoT gets compromised during the runtime. Such isolation can be performed within the WoT Runtime using platform security mechanisms available on the device.
Depending on the device capabilities, the following isolation mechanisms might be available:
The
mechanisms
are
provided
in
the
order
from
weakest
to
the
strongest
isolation
method
and
can
be
used
in
combination.
In
order
to
choose
the
appropriate
mechanism
one
should
study
the
capabilities
of
the
underlying
device,
as
well
as
evaluate
the
risk
level
of
particular
deployment
scenario
(see
Section
2.4
Determining
a
suitable
security
architecture
for
more
details
on
how
to
evaluate
the
risk
level).
scenario.
It
is
also
important
to
note
that
all
isolation
mechanisms
usually
affect
performance
and
might
require
non-trivial
policy
setup
and
management.
Now
if
we
consider
the
basic
communication
scenario
between
the
WoT
Client
and
the
device
exposing
the
WoT
Thing
described
in
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
from
a
perspective
of
script
instances
running
inside
WoT
Runtime,
each
such
instance
should
be
able
to
have
a
way
to
perform
mutual
authentication
between
itself
and
a
remote
WoT
Client
or
support
the
a
token-based
authentication
methods.
This
means
that
each
script
instance
should
have
a
way
to
access
the
security
metadata
containing
all
required
credentials
or
alternatively
have
a
set
of
APIs
provided
by
method.
However,
there
are
no
methods
in
the
WoT
Runtime
Scripting
API
to
perform
required
cryptographic
operations
on
credentials
stored
by
any
such
tasks.
Instead
the
underlying
WoT
Runtime
itself.
Editor's
note
and
protocol
bindings
handle
the
required
security
functionality
transparently
for
the
WoT
scripts.
Figure
12
:
shows
how
it
is
done,
when
a
WoT
Script
discovers
a
new
WoT
Thing,
MyLampThing,
using
the
discover()
scripting
API
method,
and
invokes
an
action
"toggle".
Figure
13
shows
handling
of
security
configuration
during
the
exposure
of
a
new
WoT
Runtime
currently
have
any
APIs
to
work
with
Thing,
MyLampThing.
Since
the
security
metadata?
If
not,
how
is
this
envisioned
configurations
(types
of
authentication
and
authorization
methods
and
corresponding
credentials)
are
not
exposed
to
be
done,
the
WoT
Scripts,
but
handled
by
exposing
the
credentials
directly
WoT
Runtime
and
underlying
protocol
bindings,
WoT
Scripts
must
either
rely
on
the
WoT
Runtime
to
use
the
scripts
or
by
relying
on
underneath
levels
default
credentials
provisioned
to
do
it?
This
needs
more
clarification
it,
or
indicate
the
choice
of
security
methods
and
explanation.
credentials
using
a
name/id
tag
known
to
the
WoT
Runtime.
Figure
7
WoT
Servient
Multi-Tenant
14
shows
the
WoT
Servient
with
two
different
tenants
running
in
two
different
instances
of
WoT
Runtime.
There
is
a
no
trust
relation
between
different
tenants
and
they
can
be
untrusted.
Each
tenant
can
have
multiple
independent
WoT
scripts
running
inside
their
WoT
Runtime.
WoT
Runtime
core
also
has
a
Thing
Manager
entity
that
allows
installation
of
scripts
into
the
corresponding
WoT
Runtimes.
The
case
of
the
multi-tenant
servient
with
a
possibility
to
install
the
WoT
Scripts
remotely
into
the
WoT
Runtimes
brings
an
additional
set
of
threats
that
must
be
taken
into
account:
WoT
Script
Management
Interface
Threat
,
WoT
Untrusted
Script
Threat
-
Script
Compromise
,
WoT
Untrusted
Script
Threat
-
Runtime
Compromise
,
WoT
Untrusted
Script
Threat
-
Authenticity
,
WoT
Untrusted
Script
Threat
-
Confidentiality
,
WoT
Untrusted
Script
Threat
-
TD
Authenticity
,
WoT
Untrusted
Script
Threat
-
TD
Confidentiality/Privacy
Confidentiality
and
Privacy
,
WoT
Untrusted
Script
Threat
-
Thing
System
User
Data
Authenticity
,
WoT
Untrusted
Script
Threat
-
Thing
System
User
Data
Confidentiality
and
Privacy
,
and
WoT
Untrusted
Script
Threat
-
DoS
.
In order to address these threats one should utilize the strongest isolation method available on the device to separate different WoT Runtimes. The isolation should cover execution context, runtime memory, local storage and resource allocation between different WoT Runtimes.
In
addition
the
Thing
Manager
should
have
a
reliable
way
to
distinguish
between
different
tenants
in
order
to
securely
manage
provisioning
and
updates
of
scripts
into
the
corresponding
WoT
Runtime.
This
can
be
achieved
by
authenticating
the
tenant
using
one
of
the
authentication
methods
described
in
Section
5.1
7.1
Basic
Interaction
between
WoT
Thing
and
WoT
Client
.
Do we want to describe/point to examples how provisioning could be done?
Also
each
tenant
inside
the
WoT
runtime
requires
a
different
set
of
security
metadata
credentials
to
be
provisioned
and
made
accessible
for
its
scripts.
This
metadata
These
credentials
should
be
also
strictly
isolated
between
different
tenants.
In this section we give overall guidelines on how a deployed WoT network should be validated and tested from the security perspective.
This section content needs to be added. See the security validation section of the WoT Testing plan in the meantime.
Please refer to the WoT Architecture document for terminology definitions.