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 for guidance,
it should be possible to 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 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.
This content should be consistent with the summaries in the
Security sections of other WoT documents, in particular the
WoT Architecture
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.
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
which includes the following states:
Manufactured: The WoT device has been manufactured by an OEM.
It might have a WoT runtime present that enables single or multi-tenant users
or it might only have network interfaces exposed present that are compatible with a WoT description.
From the Manufactured state, based on the deployment scenario, the device can transition to either of two states:
the Installation/Commissioning state or the Security Provisioning state.
Installation/Commissioning: A WoT device has been installed into its intended deployment environment
by a system provider or system integrator and any necessary SW configuration has been performed.
In practice this state may be combined with or reordered with the Security Provisioning state.
Security Provisioning: A WoT device is provisioned with the security metadata and credentials needed
during its Operational state.
The exact set of necessary credentials will vary based on the WoT device's deployment model and choice of security mechanisms.
The document The State-of-the-Art and Challenges for the Internet of Things Security [[Garcia17]]
refers to this stage as "Bootstrapping".
Operational: The default operational state of WoT devices.
Devices in this state are fully ready to communicate over WoT interfaces and satisfy their deployment's operational roles.
From the Operational state a device can return to the Manufactured state
if it is fully decommissioned and security de-provisioned
(link E in Figure ).
It is also possible to perform only a partial reset of a device,
if it only requires re-installation and recommissioning without security re-provisioning
(link D in Figure ).
It is also possible that only security re-provisioning is needed
without re-installation and re-commissioning (link C in Figure ).
Maintenance and Security Update:
A state that is entered when the device's software or configuration needs to be updated.
This is an optional state that can be activated remotely or locally (link A in Figure )
on a WoT device depending on the deployment model and overall setup.
This state can be required to maintain security,
for example to patch SW vulnerabilities or perform security-related configuration updates,
such as key revocation or certificate refresh.
After maintenance or updates are done,
the device normally returns to the Operational state (link B in Figure ).
The scope of this document only covers the Operational State of a WoT device
with the assumption that all relevant security metadata and credentials has been
successfully provisioned during the Security Provisioning state and
are available transparently to the WoT runtime level.
Security-related system management updates (such as the revocation and update of keys and other credentials),
while important to maintaining the security of a system, are considered to be out of the scope of this document.
Requirements
General
In general using the WoT approach should "do no harm": the security of any protocols should be maintained.
The Web of Things does not introduce new security mechanisms,
but should preserve the functionality and security of existing mechanisms.
We also have the following requirements:
Exposing:
When exposing a TD, especially via the Scripting API,
it should be possible to use best practices for security,
including maintaining the integrity of the TD and delivering it only to authorized recipients.
Consuming:
A consumed TD should accurately reflect the actual security status of the device it describes.
Protocols:
The WoT can potentially apply to many protocols but to limit scope in this
discussion we will focus on the needs of HTTP(S), CoAP(S), and MQTT(S).
Threat Model
Due to the large diversity of devices, use cases,
deployment scenarios and requirements for WoT Things,
it is impossible to define a single WoT threat model that would fit every case.
Instead we 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.
WoT Primary Stakeholders
This section lists the primary WoT stakeholders.
Stakeholder
Description
Security goals
Edge cases
Device Manufacturer (OEM)
Producer of the HW device.
Implements the WoT runtime on the device,
defines Things that the device provides, and generates TDs for these Things.
Don't want the devices they make to be used in any form of attack
(due to loss of reputation and possible legal consequences in some countries).
Want to satisfy the security requirements of System users
and System providers to maximize HW sales.
System Provider or
System Integrator or
System Installer
Uses devices from OEMs to build various WoT end solutions
specific to particular WoT use case(s).
An OEM might simultaneously be a System Provider,
although System Providers might also
define new TDs or modify TDs provided by other entities (OEMs).
System Providers
might use the WoT scripting API and runtime to implement their solution
or might do a full reflash of the device to install their own software stack.
A System Provider's scripts and their configuration data might require
confidentiality and/or integrity.
A System Integrator/Installer is similar to a System Provider but tends to
reuse rather than create new technology.
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 System users for better sales.
Don't want security to interfere with usability for better sales
(usability vs. security).
Want their WoT network to be robust and be resistant to DoS attacks.
Want to hide their proprietary scripts and other relevant data from other parties.
There might be several independent system providers (tenants) on a single HW device.
In that case isolation between them is required while (perhaps) sharing
user preferences and identification.
System User
These might be physical users (e.g. John and his family in their smart home)
or abstract users (e.g. the company running a factory).
The primary characteristic of this stakeholder is the need to use
the WoT Network to obtain some functionality.
System Users entrust WoT systems with their data
(video streams from home cameras or factory plans) or physical capabilities
in the surrounding environment (put lights on in a room or start a machine on the factory line).
They might differ in their access to the WoT network
and transferred data (for example, they might only be able to configure
certain parts of the network or only use it as it is).
Don't want their data to be exposed to any other System User,
System Provider or OEM unless intended (Data Confidentiality).
Don't want their data to be modified unless intended (Data Integrity).
Access to user data might be configurable based not only on "who"
is the entity accessing the data (access control subject),
but also his/her/its role,
type of access, or time and context.
System Owner
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 runtimes, if such model is supported.
Any of the above stakholders can be the System Owner depending on the
concrete setup.
A WoT system might have a number of independent System Owners,
each with their own set of provisioned certificates and/or credentials.
Underlying IoT protocol suites may also have their own notion of ownership.
Want to have a full control over their own provisioned security credentials,
including their integrity and confidentiality.
System Maintainer
This is an optional stakeholder.
It administers a WoT system on behalf of a System Provider
or System User
Needs to have enough access to the WoT system to perform its dutes.
Should have minimal (ideally none) access to the data of other stakeholders.
Assets
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 TDs.
They are managed using a discretionary access control model
(the owner of a TD sets the AC policy).
Some contents of TDs might be privacy sensitive and therefore should not be shared without a specific need.
The integrity of TDs is crucial for the correct operation of a WoT system.
TD owner: full access
Others: read only for minimal required part.
Storage on thing itself, cloud storage, in-transfer (network) including TD updates.
System User Data
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 System Users might have different levels of
access to this data based on the use case. In some cases (like user preferences or settings)
the partial access to this asset is also needed by a System Provider.
Non-authorized access must be minimized since access even to a small amount of information
(for example the last timestamp when a door lock API was used) might have severe
privacy concerns (this example would allow an attacker to detect when the owner is away
from his house).
Security mechanisms should be flexible to configure and might also need to include RBAC.
Others: should have no access unless specifically allowed
Storage on the device itself, remote solution provider storage (Cloud or other),
in-transfer (network)
System Provider Data
This includes both WoT scripts and any WoT configuration data produced and owned by a
System Provider. It also includes Thing instances, i.e.
run-time representations of scripts running inside a WoT Runtime.
System providers might have Intellectual Property (IP) in their scripts,
making them highly confidential.
Protocol Bindings might be part of System Provider Data,
if a WoT device has a single System Provider that
installs and configures WoT Runtime and Protocol Bindings.
However, these can be also provided and confgured by the OEM,
and the same Protocol Bindings could be used by
multiple System Providers on the same device.
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 purposes.
An actuator capability also implies a possible safety risk.
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.
Thing Manager (if present in WoT Runtime), WoT Runtime
On device storage, in-transfer including provisioning and updates of security metadata.
If a WoT system allows co-existence of different independent 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 system providers on the device.
Not required if a simple baseline policy of "full isolation" is applied
to different WoT Runtimes running scripts from different System providers.
It might be required if some level of data sharing between them is needed.
Storage on the thing itself, remote storage (if they are backed up to a remote storage),
in-transfer for initial provisioning and policy updates
Adversaries
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 Man-in-the-Middle (MitM) attacks,
drop, delay, reorder, re-play, and inject messages.
This attacker type also includes a passive network attacker, where an attacker is only able to passively
observe the WoT network traffic.
Malicious Authorized User
Unauthorized access of private data of any other stakeholder (eavesdropping).
Unauthorized modification of data of any stakeholder
(modification of sensor data, or script modification).
Obtaining higher privileges than originally intended by the System Owner
(for example, a hotel guest trying to control overall hotel lighting).
Local physical access, WoT Client interface (smartphone, web interface, washing machine interface, etc.)
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
If a WoT system allows the co-existence of different independent System providers (tenants)
on a single physical device, the following adversaries are added:
Unprivileged software adversary:
System provider scripts running on the same HW device, but inside a different WoT runtime
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 System Provider
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
Attack Surfaces
In order to correctly define WoT attack surfaces one needs to determine the system's
trust model as well as execution context boundaries.
A high-level view of the WoT architecture from the security point of view is presented in
,
showing all possible execution boundaries.
However, in practice certain execution boundaries might not be present as they are
dependent on the actual device implementation.
WoT High-Level Architecture Security View
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 have a higher chance of being compromised remotely
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 isolation,
but in addition can be implemented using any stronger security measures available
on the device (Mandatory Access Control, OS-kernel level virtualization,
Full Virtualization etc.)
This boundary is required if we assume that we have different System Providers
running on the same device in different WoT Runtime Instances.
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 using OS process isolation,
but in addition can be implemented using any stronger security measures available
on the device (Mandatory Access Control, OS-kernel level virtualization,
Full Virtualization etc.)
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 using OS process isolation.
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
The following WoT attack surfaces are only in-scope for the WoT security model
if we assume a WoT runtime can run untrusted scripts
or we assume co-existence of different System Providers (tenants)
on a single physical device:
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.
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, 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 WoT asset
Any remote or local attack method on a non-WoT endpoint that
results in an attacker obtaining unauthorized access or the ability to
modify any WoT asset stored at the non-WoT endpoint or to cause any
type of DoS attack on WoT Thing Resources or WoT
Infrastructure Resources
This attack surface is out of scope because WoT specifications do
not cover non-WoT endpoints.
Native device compromise
Component compromise on levels below WoT Runtime,
including any WoT component, such as WoT Gateway Servients,
WoT Clients or WoT Things.
Any type of the WoT assets
Any remote or local attack method on WoT devices (WoT Gateway Servient,
WoT Client, WoT Thing device, etc.) on levels below WoT runtime that
results in attacker obtaining unauthorized access or the ability to
modify any WoT asset stored at the WoT Runtime or to cause any type
of DoS attack on WoT Thing Resources or WoT Infrastructure
Resources
This attack surface is out of scope because WoT specifications do
not cover levels below the WoT Runtime.
Threats
This section lists all basic WoT 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 be installed by untrusted parties.
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 Developer
also access to solution user credentials available on the configuration interface
(smartphone, tablet etc.) 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
Pre-conditions:
An attacker with an access to a WoT Interface Attack method:
Any remote attack method using a WoT Interface
with the purpose of obtaining unauthorized access to a WoT asset
Pre-conditions:
General preconditions for an attacker with access to a WoT Interface Attack method:
Any attack method using a WoT Interface in order to
cause Denial-of-Service (DoS) to an end thing,
device, service, or infrastructure
(calling WoT Interface methods that require excessive processing,
sending too many messages etc.)
or to disturb the service operation by intentional dropping
of all or selective WoT messages
Pre-conditions:
General preconditions for network attacker with access to a WoT Interface Attack method:
Any attack method on a TD in-transfer with the purpose of its modification,
including rolling back to an older version of that TD
WoT Communication Threat - TD Confidentiality and Privacy
Confidential and privacy-sensitive parts of TDsin-transfer
Pre-conditions:
General preconditions for network attacker with access to a WoT Interface 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 TDs in-transfer
WoT Communication Threat - System User Data Authenticity
Pre-conditions:
General preconditions for network attacker with access to a WoT Interface 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 - System User Data Confidentiality and Privacy
Pre-conditions:
General preconditions for network attacker with access to a WoT Interface Attack method:
Any attack method on solution data in-transfer with the purpose of obtaining
unauthorized access
Pre-conditions:
General preconditions for network attacker with access to a WoT Interface Attack method:
Passive observation of WoT network and messages with the intention to learn
behavioral and operational patterns
We may need to add threats related to credentials/policy management
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:
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 a WoT Script Management API Attack method:
Attacker installs its own script into WoT runtime using a WoT Script Management Interface
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 Management API Attack method:
Attacker compromises WoT Runtime itself using a WoT Script Management Interface
Pre-conditions:
General preconditions for network attacker with access to the WoT Script Management API Attack method:
Attacker misuses WoT Script Management Interface to cause DoS on things or infrastructure,
including deleting or corrupting WoT scripts
If a WoT system allows co-existence of different independent System Providers (tenants) on a
single physical device or if WoT scripts are assumed to be untrusted,
the following new threats appear in addition to the above ones:
Component compromise and all WoT assets within the same execution boundary
Pre-conditions:
An attacker has full control over a script running inside a WoT runtime either
legitimately (System Provider Script)
or by compromising a System Provider Script or
by installing their own script by other means. 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
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
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
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 to modifying that script or its configuration,
including rolling back to an older version of the script
WoT Untrusted Script Threat - TD Confidentiality and Privacy
TDs confidentiality and privacy as stored on a thing
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.
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 acheiving unauthorized modification of a TD,
including rolling back to an older version of that TD
WoT Untrusted Script Threat - System User Data Authenticity
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 System User Data,
including rolling back to an older version
WoT Untrusted Script Threat - System User Data Confidentiality and Privacy
Here we describe some typical high-level WoT scenarios and give practical examples of the above threats
for each scenario.
Scenario 1 - Home Environment
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 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; a single System Provider exists on physical
WoT devices; and no dynamic installation of WoT scripts is possible.
In this scenario the following WoT Threats are possible:
A compromised application on a user smartphone connected to the same internal network as WoT devices sends
a malformed request to a WoT device targeting the Protocol Bindings interface directly.
This malformed request causes
the respective Protocol Binding to be compromised (e.g. by exploiting a buffer-overflow bug)
and the attacker is able to run code with the privileges of
the Protocol Binding on the WoT device.
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 code with the privileges of the Thing Instance on
the WoT device.
A user's party guest with network access to the same internal network as WoT devices uses his device
to send a WoT interface request to a user's WoT device for a certain resource access, for example, to get a
video stream from user's video camera footage or permission to unlock some rooms in the house. Due to lack of
proper authentication, he is able to access this information or execute the required action (e.g. opening the
targeted door).
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 sent by one of the WoT devices. Then it modifies the TD
to state different authentication method or authority and forwards it to the intended device. The device
follow the instructions in the modified TD and sends authentication request to the attacker's specified
location potentially revealing its credentials, such as username and password. Similarly instead of modifying the
legitimate TD, an attack might save it and use iit later on, for example when it would be updated to a newer
version. Then, an attacker substitutes a new version of the TD with an older version to cause DoS to a device
trying to get an access to a resource. An additional reason for using an older TD might be exposing a
previously available vulnerable interface that got hidden when the TD was updated to a newer version. This can
be a stepping stone to conducting other attacks on the WoT network.
A user's party guest with network access to the same internal network as WoT devices using his device
listens to the network and intercepts a legitimate TD send by one of the WoT devices. While inspecting the TD
he/she learns privacy-sensitive information about the host, such as presence of medical tracking or
assistant equipment, name of healthcare provider company etc.
An example of privacy threat: a compromised application on a user smartphone connected to the same internal
network as WoT devices listens for publicly broadcast TDs and sends this data to a remote attacker to build
a profile of devices installed in the home and their purpose.
A user's party guest with network access to the same internal network as WoT devices using his device
listens to the network and intercepts a legitimate WoT interface request to set some settings on some
actuator, for example the time when house doors get locked and unlocked. He then modifies the specified value
to the desirable one and then forwards the request to the destination WoT device. The destination WoT device
accepts incorrect settings. 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 might damage the heating equipment. Another
attack involves replaying an old legitimate WoT interface request that attacker intercepts while visiting the
user's home, such as commands to unlock doors, stop camera recordings etc. from a different time when the user
wants to get authorized access to the house.
A user's party guest with network access to the same internal network as WoT devices using his device
listens to the network and intercepts WoT interface exchange between legitimate entities. From that exchange
the guest learns privacy-sensitive information about the host, such as a data stream from his medical
tracking equipment, information about user's preferences in home environment, video/audio camera stream etc.
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 take all the processing bandwidth of a
WoT device or WoT network and make it impossible for legitimate users to communicate with WoT devices or
devices to communicate with each other. Depending on the implementation it can also lead to the case that
alarm or authentication systems might be disabled and thieves get into user's house (however systems should
always implement "safe defaults" principle and in such cases keeps doors closed despite of inability to
authenticate).
A compromised application on a user smartphone connected to the same internal network as WoT devices
listens to the WoT network traffic.
By this passive listening, he is able to infer various forms of privacy-related
information, such as WoT system configuration, WoT devices that are present,
network active and passive phase timing,
etc.
Scenario 2 - Business/Corporate Environment
In this scenario we assume an office building environment shared between a number
of independent companies (tenants) with a shared WoT network running that controls temperature, lights, video
surveillance, air etc.
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 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 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.
In this scenario the following WoT Threats are possible:
This attack is similar to the one described in Scenario 1 where a WoT network shares
connectivity with other non-WoT devices (smartphones, PCs, etc.).
In this case a company's employee can send a malformed request to a WoT device targeting a
Protocol Binding interface directly.
This malformed request causes the respective Protocol Binding to be compromised and attacker
is able to run the code with the privileges of the Protocol Binding on the WoT device.
As a result the attacker can get any WoT asset from that device, including System User Data
from another company.
An employee with network access to the same internal network as WoT devices using his device
sends a WoT interface request to obtain the data from a WoT video camera device located in a meeting
room of another company or to unlock the door to another company's office wing. Due to lack of proper
authentication, he is able to access this information or execute the targeted action
(e.g. opening the door and getting physical access to another company's premises).
If we assume that all Things and their TDs are standard to
the building, then unlike Scenario 1 we can (perhaps) assume that all info in them is public
(since they relate to System provider and not system users). However, if companies or employees
can add their own devices to the WoT network (for instance, wearables or desk lamps) than
the system may have to protect non-public TDs.
Similar to Scenario 1, but the attack can be done by an employee with network access to the same
internal network as WoT devices. In case this if the attack succeeds, an attacker may be able to control other's
company WoT devices using actuator capabilities (including unlocking doors), changing important settings
(such as heating controls, disrupting a company's business activities) etc.
Similar to Scenario 1, but the attack can be done by an employee with network access to the same
internal network as WoT devices. In case this if an attack succeeds, an attacker may learn other's company
confidential information, and get access to the privacy-sensitive information of other's company clients
and employees (including, for example, employee presence information).
An employee with network access to the same internal network as WoT devices using his device
sends a huge number of requests to either a single WoT device or all devices available in the WoT network
using either the Protocol Bindings interface directly or the WoT interface.
These requests consume all the processing or bandwidth of a WoT device or WoT network and make it impossible
for employees of other company to communicate with WoT devices or devices to communicate with each
other. Depending on the implementation it might also lead to alarm or authentication systems
being disabled and allowing attackers to get into other company's premises (however systems should always
implement "safe defaults" principle and in such cases keeps doors closed despite of inability to
authenticate; but this causes the opposite problem of denying authorized users access and disrupting
legitimate business).
In this scenario we assume an industrial factory or infrastructure (power plant, water distribution
system, etc.) environment that is using WoT network
to monitor or perform certain automation 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.
Privacy Considerations
In this section we focus specifically on the privacy aspects that are important to keep in mind
while developing and deploying WoT solutions.
The threat model, described in ,
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.
The following WoT privacy threats can potentially affect the privacy of WoT system users:
Privacy threat name
Details
Mitigation
Disclosing WoT Thing/Device configuration
Thing Descriptions (TDs) might leak privacy-sensitive information, such as
detailed configuration of a single WoT Thing.
WoT TDs should minimize the amount
of information that is publicly available about a WoT Thing.
There has to be a way (if a TD is privacy-sensitive) to limit clients who can
obtain a certain TD (or its privacy-sensitive parts) via authentication and
authorization methods.
It is also possible to expose a number of TD variants
for the same WoT Thing based on the level of client's access.
This recommendation corresponds to the data minimization
and security (unauthorized usage, peer entity authentication and confidentiality)
treat mitigation strategies outlined in
[[Coo13]] - Privacy Considerations for Internet Protocols.
Disclosing WoT System configuration
Privacy-sensitive information might be inferred via observing the communication
between a WoT endpoint (Client, Servient or Device) and a Thing Directory.
For example one can learn information about the configuration of a target
WoT system by observing the TDs
that the target WoT system downloads from a Thing Directory.
In addition, loading JSON-LD context files might also leak WoT System configuration.
For example, context files may be used to allow TDs to be extended with
new protocols and security schemes; loading these context files then
implies the TDs uses these protocols or schemes.
The communication between WoT endpoints and a TD distribution service (i.e. Thing
Directories) should be protected against eavesdroppers using well-established
security protocols. It also should not be possible for a casual observer
(for example, a guest visiting a person's home with access to a private wireless access point)
to query available WoT devices (there has to be a way to limit WoT devices'
ability to respond to different broadcast events) and as a result obtaining
WoT System configuration.
Caching on gateways can help with the JSON-LD context files loading problem.
This recommendation corresponds to the data minimization
and security (unauthorized usage, peer entity authentication and confidentiality)
treat mitigation strategies outlined in
[[Coo13]] - Privacy Considerations for Internet Protocols.
Depending on the network topology, WoT System User Data can be transferred
between the WoT Client and WoT Device via many intermediate nodes, such as a WoT
Servient Gateway or non-WoT nodes. If these nodes can access or process the WoT
system user data, they can unintentionally leak information impacting
the privacy of WoT System Users.
In addition, if WoT interfaces are publicly
accessible (for example allowing anyone to query the state of WoT Thing),
it can also leak WoT
System User Data.
WoT things should minimize publicly accessible WoT interfaces.
If WoT System User Data is privacy-sensitive and travels via intermediate
nodes, end-to-end encryption methods and object level security should be preferred.
This recommendation
corresponds to the data minimization and security (inappropriate usage,
unauthorized usage and confidentiality) treat mitigation strategies outlined in
[[Coo13]] - Privacy Considerations for Internet Protocols.
Tracking WoT System User
According to the WoT specification, each TD includes a unique identifier (id), but it
is not specified how such identifier should be generated and the duration of its
validity.
Typically such identifiers are generated using various methods outlined in
[[Lea05]] - A Universally Unique IDentifier (UUID) URN Namespace.
If this identifier is a persistent unique identifier that is never changed during device
lifecycle (immutable) or changed very rarely (for example only when a WoT system is
installed and bootstrapped), then a WoT device and a WoT System User might
be uniquely identified and its communications tracked.
Similar tracking can be done even without identifiers by using
fingerprinting techniques based on
a WoT System configuration information (which is likely to be unique).
A TD should avoid exposing publically any persistent unique identifiers
(especially immutable ones)
that can be used to track it.
Ideally, a TD's identifier (id) should be changed
periodically (potentially even every time the WoT Thing instance is created, if it does
not infer the normal operation mode of a WoT Thing).
This however conflicts with the needs of Linked Data and the registration of
Things in directories and their use by other Things.
A compromise needs to be struck. Mechanisms to notify
legitimate users of a Thing when a Thing's identifier has changed may be considered
if frequent updates are necessary.
It should be at least possible to change a Thing's identifier
by re-provisioning the device if necessary.
Using methods to limit disclosure of WoT system configuration and TDs also helps to prevent
tracking of WoT System users.
In addition to the mitigations described above, it is also important to keep System Users
informed about the information that can be exposed and/or collected about them, as well as to have
a way for System Users to control the degree of such exposure.
This recommendation
corresponds to the user participation in treat mitigation strategy outlined in
[[Coo13]] - Privacy Considerations for Internet Protocols.
We may need to mention privacy risks associated with links.
In particular, dereferencing links carries similar inferencing risks
as context file dereferencing.
References to Existing Security Best Practices
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 some of the more useful points of reference:
[[Garcia17]] - State-of-the-Art and Challenges for the Internet of Things Security:
This IETF document, a product of the IETF T2TRG, is still in draft form but is now a candidate for
ratification.
It covers a range of recommendations for securing IoT systems.
Readers should look for the latest version using the IETF RFC tracker.
[[IicSF16]] - The Industrial Internet of Things Volume G4: Security Framework:
Focuses on industrial IoT systems and use cases, and so as discussed above
emphasizes safety over privacy considerations.
However, this document includes many practices that are also relevant to other IoT use cases.
[[IETFACE]] - IETF Authentication and Authorization for Constrained Environments (ACE):
Discusses the use of existing IETF standards for constrained environments
(such as CoAP and DTLS) of relevance to IoT.
This document also defines a generic IoT security architecture that is followed by several IoT standards.
[[ISF17]] - IoT Security Foundation Best Practice Guidelines:
A general set of recommendations for managing the security of IoT systems,
including lifecycle management.
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.
[[Mic17]] - STRIDE - Internet of Things security architecture
[[Nis15]] - NIST Guide to Industrial Control Systems (ICS) Security
[[Owa17]] - OWASP Threat Risk Modeling
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.
[[Coo13]] - Privacy Considerations for Internet Protocols
[[Res03]] - IETF Guidelines for Writing RFC Text on Security Considerations
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:
[[CoRE-RD]] - CoRE Resource Directory
[[Bel89]] - Security Problems in the TCP-IP Protocol Suite
[[Bel13]] - Web Security in the Real World
[[Ber14]] - Authentication Protocols, Web UX and Web API
[[Bor14]] - Terminology for Constrained-Node Networks
[[Bru14]] - Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations
[[Dur13]] - Analysis of the HTTPS Certificate Ecosystem
[[Ell00]] - Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure
[[Fu01]] - Dos and Don’ts of Client Authentication on the Web
[[Geo12]] - The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software
[[Gol03]] - Cryptography and Cryptographic Protocols
[[Gre14]] - How do you know if an RNG is working?
[[Gut02]] - PKI: It’s Not Dead, Just Resting
[[Hea13]] - An update on our war against account hijackers
[[Iic15]] - Industrial Internet Reference Architecture
[[IicRA17]] - The Industrial Internet of Things Volume G1: Reference Architecture
[[Jon14]] - A JSON-Based Identity Protocol Suite
[[Ken03]] - Who Goes There? Authentication Through the Lens of Privacy
[[Lam04]] - Computer Security in the Real World
[[Loc05]] - Demystifying SAML
[[Mel15]] - Securing the Industrial Internet of Things
[[Moo02]] - A critical review of End-to-end arguments in system design
[[Oos10]] - Provisioning scenarios in identity federations
[[Sch14]] - The Internet of Things Is Wildly Insecure — And Often Unpatchable
[[Sch99]] - Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards
[[She14]] - The Constrained Application Protocol (CoAP)
[[Vol00]] - AAA Authorization Framework
[[Yeg11]] - Stevey's Google Platforms Rant
Should use references from global ReSpec bibliography whenever possible,
rather than local bibliographic entries.
Best Security Practices and Mitigations for WoT Systems
Based on the main WoT assets,
privacy and security threats listed in ,
and
, we provide here a set of recommended practices for
enhancing security and privacy when designing 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 Practices for designing a Thing Description
Secure Delivery and Storage of Thing Description.
When a TD is transferred between WoT endpoints, to or from the TD
hosting service, it is important to use secure protocols guaranteeing
data authenticity, freshness and in many cases confidentiality
(depending on whenever a TD contains any confidential or
privacy-sensitive information).
TDs should not be provided without first authenticating the requester
and checking that they have authorization to access the requested TDs.
If end-to-end TD authenticity or
confidentiality is required, see
for more specific guidance.
When a TD is stored at the end device, in a gateway (e.g. in a cache or directory
service) or in remote storage (e.g. an archive),
its authenticity and in some cases confidentiality should
also be protected using the best available local methods.
When defining fields exposed by a TD immutable information should be avoided,
especially if that 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 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.
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 implementions.
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.
When defining protocols for APIs exposed by a TD,
it is often important to use secure protocols guaranteeing
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.
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.
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.
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.
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).
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 a WoT Thing.
Secure Practices for Thing Directory Interaction Protocols
This subsection content needs to be added.
Secure Practices for end-to-end security
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.
The WoT is intended to be used in variety of use cases and deployment configurations.
While the examples in this section do not cover all possible deployment variations, they cover
many common cases, shows how security mechanisms can be configured for these cases,
and highlights some details relevant to security.
Basic Interaction between WoT Thing and WoT Client
shows the basic WoT Client
(which can be a browser or an application on a user's smartphone)
used to directly operate a WoT Thing.
The WoT Thing exposes a WoT network interface and also directly provides
a Thing Description.
The Thing Description describes the interactions that can be performed on the WoT Thing.
Basic WoT Thing and WoT Client
From a security point of view two aspects are important to consider in this scenario.
First, the WoT Client should be certain that it is talking to the correct WoT Thing
and not to some other device exposed on the same network.
Users intending to control a specific device, for example opening a garage door,
want to make sure they are talking to their own garage door device.
In security terms this means that WoT Client must have a way to
authenticate the device exposing the WoT Thing.
Second, upon receiving requests from a WoT Client,
the WoT Thing must verify the the WoT Client is authorized to perform such requests.
For example, a garage door must only process "open" requests from devices associated with
authorized users or service providers and not from arbitrary passerby.
These requirements can both be fulfilled using a variety of different security mechanisms.
The choice of concrete security mechanisms depends on the deployment scenario,
as well as capabilities of the devices.
Either or both the WoT Client and the WoT Thing might have some 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 providing the network interface acting as the WoT 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 provisioning:
Symmetric key credentials.
This method assumes that both WoT Client and the device exposing WoT Thing have pre-shared
symmetric key credentials.
Such keys can be established during device provisioning/on-boarding phase.
In this case, since this is actually an OCF device,
it can use one of the methods recommended in Section 7 [[Ocf17]]
or can use an ad-hoc security protocol,
such as EC Diffie-Hellmani, based on other existing pre-shared credentials.
See Section 9.2.1 [[Ocf17]] for more details on such credential types.
Raw asymmetric public key credentials.
This method assumes that a WoT Client has been provisioned with the public key
of the device exposing the WoT thing (and vice versa)
so the devices are able to mutually authenticate each other.
Provisioning of public keys can take place during a device provisioning/on-boarding phase.
In the case of OCF devices,
this can take place using one of the methods recommended in Section 7 [[Ocf17]].
Section 9.2.3 [[Ocf17]] also provides more details on this credential type as well as
guidance on its secure provisioning.
Certificates. This method assumes that the WoT Client has been provisioned
with the certificate of the device exposing the WoT thing (and vica versa)
so the devices are able to mutually authenticate each other.
The provisioning of the certificates can take place during device provisioning/on-boarding phase
using one of the methods recommended in Section 7 [[Ocf17]].
Section 9.2.5 [[Ocf17]] also provides more details on this
credential type as well as Section 9.3.
In case it is not possible to pre-provision any of the types of credentials described above
during the network setup phase or if the WoT Thing wants to use a more fine-grained access control policy
on the WoT network interfaces it is exposing
(for example, different controls might require different levels
of authorization), the following methods can be used instead:
OAuth 2.0-based access tokens. These tokens follow the JSON Web Token (JWT)
format defined in RFC 7519 [[JWT15]] and should used according to the suggestions by
the IETF Authentication and Authorization for Constrained Environments (ACE)
specification draft [[IETFACE]].
These are recommended for devices that are able to use the HTTP protocol and
do not have significant resource constraints.
Proof-of-possession (PoP) tokens. These are extensions of the OAuth 2.0-based
access tokens that follow the CBOR web token (CWT) format [[CBOR17]].
The IETF Authentication and Authorization for Constrained Environments (ACE)
specification draft [[IETFACE]]
recommends such tokens for resource-constrained devices using the COAP protocol
instead of HTTP.
For details of using such tokens please see [[IETFACE]].
Instead of assigning different access tokens to different WoT Interfaces,
it is also possible to group 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 such interfaces.
This can provide more balanced access control granularity in many circumstances.
Authenticity, confidentiality and replay protection can be guaranteed by usage of secure
transport protocols to exchange data between the WoT Client and the WoT Thing, such as TLS/DTLS.
If the underlying protocol does not provide the required security (such as plain CoAP run over
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) method described in the IETF Object Security of CoAP (OSCoAP)
specification draft [[OSCOAP17]].
The scenario shown in is similar but with the important
difference that a Thing description is not stored on the WoT Thing device nor returned by it directly.
The TD is instead provided to the WoT client from a Thing Directory residing on some other
system, such as a 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.
Basic WoT Thing and WoT Client with TD provided from a Thing Directory
The primary additional security consideration of this scenario is the need for the secure transfer
of the TD between the WoT Client and the Thing Directory.
The Thing Directory 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 secure transport protocols.
In the case that the WoT Client 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 after the download from the remote cloud.
Interaction between WoT Thing and WoT Client via a WoT Servient Gateway
A ,
as in the configuration,
also allows a WoT Client to connect to and operate or monitor a WoT Thing.
However in contrast to the basic (direct connection) case,
the interaction between the WoT Client and the WoT Thing is now mediated by a WoT Servient Gateway.
The WoT Servient Gateway exposes a WoT interface and provides a Thing Description that 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.
WoT Thing and WoT Client via Gateway
From a security standpoint this case is quite similar to the one described in
Section .
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,
as well as between the WoT Servient Gateway and the device exposing the WoT 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
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,
and may not support any interaction via 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 a trusted entity and in this case
it can freely modify or build Thing Descriptions it exposes as well as set up
fine-grained access controls on different exposed WoT Interfaces.
The WoT Servient Gateway can do this using the same methods described in
Section , i
and therefore acts fully on behalf of the end device.
is similar to the previous case
but with an important difference:
a Thing Description is not provided by the the WoT Servient Gateway,
but can be fetched by the WoT client from a Thing Directory residing on a remote system.
Similar to the previous case,
this Thing Description can either be the original Thing Description supplied by the end device
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.
Currently the use of TLS or DTLS is recommended.
Similarly to Section ,
in case the remote system does not guarantee
the secure storage and delivery of Thing Descriptions to the WoT Client
or in case the remote system is not a trusted entity,
the authenticity of the Thing Description should be verified
using other methods in the application layer.
WoT Thing and WoT Client via Gateway with Remote Cloud
Basic Interaction between WoT Thing and WoT Client via a Split Proxy
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, eg 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
in order to authenticate and authorize the WoT Client before processing any of its requests.
Similar to the configurations described in Section ,
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 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.
WoT Thing and WoT Client via Split Proxy
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.
Basic Interaction between WoT Thing and WoT Client via a Tunnel
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 .
WoT Thing and WoT Client via Tunnel
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 .
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 unencryped traffic (eg HTTP) may also be visible on the local network.
In this case, the only protection
would be from that provided by the local network, eg WPA.
If such a relatively unprotected local interace 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]].
WoT Thing and WoT Client via HTTPS/HTTP Proxy
Yet another variant of this approach is shown in .
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.
WoT Thing and WoT Client via HTTPS/HTTP Proxy
The second sub-variant, shown in ,
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.
WoT Servient Single-Tenant
In previous examples we have considered the Wot Servient as a black box
exposing a set of WoT Interfaces and Thing Descriptions.
shows the WoT Servient
(for example consider again a garage door controller device or a WoT Gateway)
in more detail with Scripting API support and a couple of scripts running inside a WoT runtime.
For this case we consider all scripts to be trusted and provisioned
to the device by a single trusted entity (for example by the manufacturer during factory installation).
WoT Servient Single-Tenant
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:
WoT Runtime enforced isolation.
This is the basic isolation provided by the WoT Runtime itself
and is based on restricting the API exposed to the scripts running within the WoT Runtime.
The exact set of guarantees depends on the concrete WoT Runtime implementation and might vary.
Native OS process-based isolation.
This method relies on the underlying native OS to provide basic isolation guarantees
based on native process isolation.
The exact set of guarantees depends on capabilities of native OS,
but it usually includes at least memory and execution content isolation.
Some other mechanisms like Discretionary Access Controls (DAC) might be also available.
Native OS advanced isolation.
An OS might also provide a stronger set of measures that can be deployed for process-based isolation.
Examples of such measures are Mandatory access Control (MACs in all major OSes),
OS-level virtualization (i.e. namespaces and containers in Linux), Cryptographic methods etc.
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.
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
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 a token-based authentication method.
However, there are no methods in the WoT Scripting API to perform any such tasks.
Instead the underlying WoT Runtime and protocol bindings handle the required
security functionality transparently for the WoT scripts.
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".
Transparent handling of security during WoT Thing discovery and use
shows handling of security configuration
during the exposure of a new WoT Thing, MyLampThing.
Since the security configurations
(types of authentication and authorization methods and corresponding credentials)
are not exposed to the WoT Scripts,
but handled by the WoT Runtime and underlying protocol bindings,
WoT Scripts must either rely on the WoT Runtime to use the default credentials provisioned to it,
or indicate the choice of security methods and credentials
using a name/id tag known to the WoT Runtime.
Transparent handling of security during WoT Thing exposure
WoT Servient Multi-Tenant
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.
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 .
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 credentials
to be provisioned and made accessible for its scripts.
These credentials should be also strictly isolated between different tenants.
Security Validation
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.
Terminology
Please refer to the
WoT Architecture
document for terminology definitions.
