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,
it should be possible to build 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 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 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 content is consistent with the summary in the
Security sections of other 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.
See also:
A typical lifecycle of a WoT device is very similar to lifecycles of IoT devices. It is shown in Figure and consists from the following states:
Manufactured. At this stage the WoT device is manufactured by an OEM with a variant of WoT stack enabled. It might have a WoT runtime present that enables single or multi-tenant users or it might only have exposed WoT interfaces present. From manufactured state, the device can transition to either of two states: Installation/Commissioning state or Security Provisioning state based on deployment scenario.
Installation/Commissioning At this stage a WoT device is installed into its intended deployment scenario by a system provider or system integrator, as well as necessary SW configuration is performed. This in practice can be combined with the following Security Provisioning stage.
Security Provisioning. The main goal of this stage is to provision a WoT device with a required set of security metadata and credentials that it needs during the Operational state. The exact set of these credentials would vary based on deployment model, choice of security mechanisms etc. The State-of-the-Art and Challenges for the Internet of Things Security [[Garcia17]] document refers to this stage as "Bootstrapping".
Operational State. This is the default operational state of WoT devices. Devices are fully ready to communicate over WoT interfaces and operate to their deployment scenarios. From Operational state a device can return back to manufactured state if it is fully decommissioned and security de-provisioned (link E in Figure ). It is also possible that only partial reset on device is performed: if it only requires re-installation and recommissioning without security re-provisioning needed (link D in Figure ) or only security re-provisioning is needed without re-installation and re-commissioning (link C in Figure ).
Maintenance and security updates. 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 for example to update the SW layers of a WoT device or perform some security-related updates, such as key revocation, certificate updates etc. After the maintenance or updates are done, the device returns back to the Operational state (link B in Figure ).
The scope of this document only covers the Operation 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 available transparently to the WoT runtime level. The security-related updates (such as revocation and update of keys and other credentials) is also 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 systems does not introduce new security mechanisms,
but should preserve the functionality of existing mechanisms.
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 an authorized recipient.
Consuming:
A consumed TD should accurately reflect the actual security status of a target device.
Protocols:
We will ensure in particular that, at a minimum,
the needs of the following protocols are addressed: http(s) and coap(s).
Threat Model
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 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.
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 WoT runtime on the device, might define Things that the device provides and make TDs for these Things available.
Don't want the devices to be used in any form of attacks
(loss of reputation, possible legal consequences in some countries).
Want to satisfy security requirements of System users
and System providers for better 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.
Might define new TDs or modify TDs provided by OEMs.
Might use scripting API and runtime provided to implement their solution
or might do a full reflash of the device.
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 not easily falling down to DoS
(at least basic DoS resistance).
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 solution user preferences and identification.
System User
This might be physical users (e.g. John and his family in their smart home)
or abstract users (e.g. company running a factory). The primary characteristic of this stakeholder is the need to use WoT Network to obtain some functionality. These users would entrust WoT Network 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).
System users 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 (AC subject), but also his/her/its role,
type of access, or based on time and context.
In addition to the above stakeholders, we might need to define a notion of
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.
A WoT system might have a number of independent system owners,
each with its own set of provisioned certificates and/or credentials.
The exact hierarchy of owners that WoT wants to support is to be discussed.
Underlying IoT protocol suites may have their own notion of ownership.
We should perhaps give examples on how ownership maps from the
underlying protocol level to WoT level.
WoT Supported Physical Roles
This section list primary roles that the WoT aims to support.
We need to understand more about the System Maintainer role:
what kind of operations would it need to do?
Reflash devices, reinstall/install/remove scripts?
If it has the level of access equal to System provider,
we just talk about delegation (and there are security mechanisms to do it),
not really about a separate role.
Are there any additional roles we should support? Having only one role seems rather odd.
In particular, is the Security Owner mentioned in the previous section a role rather than a
stakeholder, and how does this overlap with System Maintainer?
Assets
This section lists all WoT Assets that are important from 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
and 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 need.
The integrity of TDs is crucial for the correct operation of WoT network.
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
Can be highly privacy sensitive and confidential.
Different system users might have different levels of
access to this data based on the use case.
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 (example allows an attacker to detect that the owner has been away
from his house).
Mechanism 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 configuration data owned by a
System Provider. It also includes the notion of a Thing instance, i.e.
run-time representation of script running inside WoT Runtime.
System providers might have Intellectual Property (IP) in their scripts,
making them highly confidential.
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 only.
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.
Corresponding Thing instances, Thing Manager (if present in WoT Runtime), WoT Runtime itself if exposes security APIs to scripts
On device storage, in-transfer including provisioning and updates of security metadata.
Need to discuss more on how the security metadata would be exposed to WoT runtime and scripts running within it.
Can be a highly sensitive asset due to privacy implications of tracking.
Need more understanding/discussion on what it is in WoT and how it is exposed via TD.
Need more understanding/discussion on what it is in WoT, model around links.
Are we talking only about links to other WoT devices, or all links?
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 Scripts Security Metadata
Defines who can provision, install, update, and remove scripts and other
System Provider Data inside a WOT runtime.
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.
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 MitM attacks,
drop, delay, reorder, re-play, and inject messages.
Malicious Authorized User
Unauthorized access of private data of any other stakeholder(eavesdropping).
Unauthorized modification of data of any stakeholder
(modification of sensor data, script modification).
Obtaining higher privileges that originally intended
(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 in 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.
presents a
high-level view of the WoT architecture from the security point of view,
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 are having 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 at least with OS process isolation means,
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 with OS process isolation means,
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 with OS process isolation means.
These boundaries might be needed if we assume that 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:
Another additional set of attack surfaces might be added
if we assume that Protocol Bindings can be untrusted.
The following attack surfaces are out-of-scope for the WoT Security model:
System Element
Compromise Type(s)
Assets Exposed
Attack Method
Non-WoT endpoints
This includes legacy devices, remote clouds and other infrastructures, user interfaces such as browsers or applications on a smartphone, etc.)
Component compromise
Any type of the WoT assets
Network attacks, local attacks
Native OS
Component compromise on levels below WoT runtime
Any type of the WoT assets
Network attacks, local attacks
Threats
This section lists all basic WoT threats, both in-scope and out-of-scope.
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 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.
We should discuss whether Protocol Bindings should be considered part of System Provider Data.
This makes sense if the System 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 System
Provider, but there may be another system provider building on top of the basic configuration
provided by the OEM.
Threat
Adversary
Asset
Attack method and pre-conditions
Non-WoT End Point Threat
All attacker types
Any type of the WoT assets
Attack method:
Any remote or local attack method on the Non-WoT End Point that results in attacker obtaining
unauthorized access or the ability to modify any WoT asset stored at
the Non-WoT End Point or to cause any type of DoS attack on WoT Thing Resources or WoT Infrastructure Resources
Native OS Threat
All attacker types
Any type of the WoT assets
Attack method:
Any remote or local attack method 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
Pre-conditions:
General preconditions for 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 the WoT Interface Attack method:
Any remote attack method using WoT Interface
with the purpose of obtaining unauthorized access to a WoT asset
Pre-conditions:
General preconditions for an attacker with access to the WoT Interface Attack method:
Any attack method using WoT Interface in order to cause DoS to an end thing,
device or infrastructure
(calling WoT Interface methods that require 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 the WoT Interface Attack method:
Any attack method on TDs in-transfer with the purpose of its modification,
including rolling back to an older version of a TD
WoT Communication Threat - TD Confidentiality/Privacy
Confidential and privacy-sensitive parts of TDsin-transfer
Pre-conditions:
General preconditions for network attacker with access to the 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 TD in-transfer
WoT Communication Threat - Thing Data Authenticity
Pre-conditions:
General preconditions for network attacker with access to the 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 - Thing Data Confidentiality
Pre-conditions:
General preconditions for network attacker with access to the 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 the WoT Interface Attack method:
Passive observation of WoT network and messages with the intention to learn
behavioral and operational patterns
Need to add all threats to credentials/policy management when we clarify how they are exposed/stored within WoT runtime
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 the WoT Script Mgm API Attack method:
Attacker installs its own script into WoT runtime using WoT Script Management Interface
Compromize 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 Mgm API Attack method:
Attacker compromises WoT Runtime itself using WoT Script Management Interface
Pre-conditions:
General preconditions for network attacker with access to the WoT Script Mgm API Attack method:
Attacker misuses WoT Script Management Interface to cause DoS on things or infrastructure,
including deleting, 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,
it brings the following new threats in addition to the above ones:
Component compromise and all WoT assets within the same execution boundary
Pre-conditions:
An attacker has a full control over the script running inside WoT runtime either
legitimately (system provider script) or by compromising a system provider script or
by installing its 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 attacker in modifying script or its configuration,
including rolling back to an older version of a script
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 attacker 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 attacker unauthorized modification of TDs,
including rolling back to an older version of TD
WoT Untrusted Script Threat - Thing 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 attacker in being able to modify system user data,
including rolling back to an older version
WoT Untrusted Script Threat - Thing Data Confidentiality
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 System providers.
Security Objectives
Practical examples of typical high-level WoT scenarios and their security objectives are given here.
Scenario 1 - Home environment
In this scenario we assume a standard home environment with a WoT network running behind a firewall 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 viewing these non-WoT devices as network attackers with access to WoT network and its APIs/Protocol Bindings. WoT scripts and protocol bindings are considered trusted, single solution provider exists on physical WoT devices, no dynamic installation of WoT scripts are possible.
This scenario implies the following WoT Security objectives:
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 directly Protocol Bindings interface. 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.
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 WoT interface. This malformed request causes the respective Thing Instance to be compromised and attacker is able to run the code with the privileges of the Thing Instance on the WoT device.
A user's party guest with the network access to the same internal network as WoT devices using his device sends 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, it is able to access this information or execute the required action (opening the 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 send 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 keys etc. Similarly instead of modifying the legitimate TD, an attack might save it and use later on, for example when it would be updated to a newer version. Then, an attacker substitutes a new version of 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 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 the 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 the privacy-sensitive information about the host, such as presence of medical tracking/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 broadcasted TDs and sends this data to a remote attacker to build a profile of home installed devices and their purpose.
A user's party guest with the 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 break heating equipment. Another attack involves replaying an old legitimate WoT interface request that attacker intercepts while visiting user's home, such as command to unlock the doors, stop camera recordings etc. in a different time when user wants to get authorized access to the house.
A user's party guest with the 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 the privacy-sensitive information about the host, such as 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 fully take 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).
Reasoning : The security of non-WoT end points and their external interfaces is out of the WoT scope. Recommendations : Solution providers and OEMs are recommended to use industry best security practices when designing their non-WoT End points, protocols and interfaces.
In this scenario we assume an office building environment that is shared between a number of independent companies with a WoT network running that controls temperature, lights, video surveillance, air etc.
This subsection content needs to be added.
This scenario implies the following WoT Security objectives:
In this scenario we assume an industrial factory or infrastructure (power plant, water distribution system) environment that is using WoT network to monitor or perform certain automation tasks.
This subsection content needs to be added.
This scenario implies the following WoT Security objectives:
This subsection content needs 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 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.
Existing Security Best Practices in related fields
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.
[[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 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.
[[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.
Recommended Security Practices
Based on the security assets and threats listed above, we provide a set of recommended practices for
enhancing security and privacy when designing various aspects of WoT network.
Secure Practices for designing a Thing Description
Secure Delivery and Storage of Thing Description
When a TD is transferred between endpoints,
it is important to at least use secure protocols guaranteeing
data authenticity and in many cases confidentiality
(depending on whenever a TD contains any confidential information)
to avoid manipulation of a TD.
If end-to-end TD authenticity 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 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 for encryption and decryption of JSON-based data structures.
When TD is stored at the end device or remote storage,
its authenticity and in some cases confidentiality should
also be protected using the best available local methods.
An access control mechanism should also be used that prevents
illegitimate modification of any of the TD's parts.
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.
Avoid Exposing Immutable Identifiers
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.
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 of access for different users.
Secure Practices for designing WoT Scripts and WoT Script APIs
This subsection content needs to be added.
Examples of WoT security configurations
WoT is intended to be used in variety of use cases and configurations. While the below list does not cover all possible deployment variations, it covers
the most common cases and shows the ways how security mechanisms can be configured for them, as well as brings attention to the relevant details.
Basic Interaction between WoT Thing and WoT Client
shows the basic WoT Client (can be a browser or application on a user smartphone) that is used to operate the WoT Thing (Garage door controller or other HW device). The latter exposes a WoT interface and provides a Thing Description with actions that can be performed on a 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 arbitrary device
exposed in the WoT network. I.e. user performing controls on the garage door wants to make sure it is talking to his or her garage door device. In security terms it means that WoT Client must have a way to
authenticate the device exposing the WoT Thing. Second, upon receiving any requests from WoT Client, WoT Thing must verify the the WoT Client is authorized to perform such requests. I.e. garage door must only process requests from devices associated with user or service provider and not from arbitrary guests in the house.
Both aspects can be fulfilled using different security mechanisms and the end decision on a concrete method depends on the deployment scenario, as well as capabilities of involved devices. The WoT Client is not expected be a resource limited device, but the device exposing the WoT Thing might have some resource constraints.
The WoT Client and the device exposing 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 the WoT network provisioning stage:
Symmetric key credentials. This method assumes that both WoT Client and the device exposing WoT Thing has pre-shared symmetric key credentials. Such keys can be established during device provisioning/on-boarding phase using one of the methods recommended in Section 7 [[Ocf17]] or using ad-hoc security protocols, such as EC Diffie-Hellman based on other existing pre-shared credentials. See Section 9.2.1 [[Ocf17]] for more details on such credential type.
Raw asymmetric key credentials. This method assumes that WoT Client has been provisioned with the public key of the device exposing the WoT thing (and visa versa) and able to authenticate the device based on it. The provisioning of public key can similarly happen during device provisioning/on-boarding phase 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 WoT Client has been provisioned with the certificate of the device exposing the WoT thing (and visa versa) and able to authenticate the device based on it. The provisioning of the certificate can similarly happen 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 Section 9.3.
In case it is not possible to pre-provision any types of credentials described above during the WoT network setup phase or if the WoT Thing wants to create a more fine-grained access control on the WoT interfaces its exposing (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 the IETF Authentication and Authorization for Constrained Environments (ACE) specification draft [[IETFACE]]. These are recommended for the devices that are able to use 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 the resource-constrained devices that are using COAP protocol instead of HTTP. For details of using such token please see [[IETFACE]].
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 provide a well-balanced access control granularity.
The authenticity, confidentiality and replay protection can be guaranteed by underlying usage of secure protocols to exchange the data between the WoT client and the WoT Thing, such as TLS/DTLS. If the underlying protocol does not provide required security measures (such as plain COAP run over non-TLS protected channel), then authenticity and confidentiality of transferred data can be implemented separately on the application layer. The recommended method for doing this in resource constrained environments is the Object Security of CoAP (OSCOAP) method described in the IETF Object Security of CoAP (OSCOAP) specification draft [[OSCOAP17]].
The scenario shown in is identical but with an important difference that a Thing description is not stored on a WoT Thing device, but provided to the WoT client from Things Directory residing on a remote cloud.
Basic WoT Thing and WoT Client with TD provided from Things Directory
The primary additional security consideration of this scenario is a secure transfer of TD between the WoT Client and Things Directory that can reside on a remote cloud or other remote location. Similarly to the methods described above such transfer should be done using underlying secure protocols. Since we do not expect the WoT Client to be 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]] by the provider of the Thing Description and verified by the WoT Client upon the download from the remote cloud.
Interaction between WoT Thing and WoT Client via WoT Servient Gateway
shows the same basic WoT Client that is used to operate the WoT Thing. However in contrast to the previous case, the interaction between the WoT Client and the WoT Thing happens via the WoT Servient Gateway. The latter exposes a WoT interface and provides a Thing Description with actions that can be performed on a Thing.
WoT Thing and WoT Client via Gateway
From a security standpoint this case is quite similar to the one described in Section with the main difference that mutual authentication should be established between all directly communicating parties, i.e. between the WoT Client and the WoT Servient Gateway, and between the WoT Servient Gateway and the device exposing the WoT Thing. If there is no direct communication between the WoT Servient Gateway and the device providing the WoT Thing the mutual authentication between them is redundant. The authentication mechanisms described in Section are also applicable for this case.
The Thing Description that WoT 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 any interaction via the WoT Interface. In this case the WoT Servient Gateway has to build the Thing Description by itself and expose it to the WoT Client. For all typical use cases, the WoT Servient Gateway should be considered as a trusted entity and it can freely modify or build Thing Descriptions it exposes as well as setup the fine-grained access controls on different exposed WoT Interfaces. It can do it using the same methods described in Section and therefore act fully on behalf of the end device.
is identical to the previous case but with an important difference that a Thing Description is not provided by the the WoT Servient Gateway, but can be fetched by the WoT client from a Things Directory residing on a remote cloud. Similar to the previous case, this Thing Description can either be 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 Thing Description between any two endpoints should be done using underlying secure protocols and the usage of TLS/DTLS is the recommended method. Similarly to Section 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.
WoT Thing and WoT Client via Gateway with Remote Cloud
Basic Interaction between WoT Thing and WoT Client via Split Proxy
shows another commonly done setup, where the WoT Thing resides in a local protected network, behind a NAT/Firewall. The WoT Thing cannot be contacted directly, but the communication between the WoT Client and the WoT Thing goes via a pair of Gateway Servients: local (residing in the local protected network) and remote (residing in the Internet in open). The Local and Remote Gateway Servients are connected with a non-WoT secure channel and the Local Gateway Servient only accepts the connections from the remote one. 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 it requests. Similar to the setups, described in Section , the authenticity, confidentiality and replay protection can be guaranteed by underlying usage of secure protocols to exchange the data 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 secured channel to the Local Gateway Servient, which in turn can issue request to the Wot Thing. The WoT channel between the Local Gateway Servient and the WoT Thing can be fully unprotected (relying purely on the closed nature of the local network), but it is strongly recommended to employ various security mechanisms described in Section to perform authentication & authorization of involved parties (WoT Thing and Local Gateway Servient), as well as to provide confidentiality and integrity of transferred solution data and TD.
WoT Thing and WoT Client via Split Proxy
An alternative security setup for such scenario can be done using end-to-end security authentication and authorization, where the WoT Client would not only need to authenticate & 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 and the exposed TD should indicate the mechanisms to obtain them.
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 again a garage door controller device or a WoT Gateway) in more details with Scripting API support and a couple of scripts running inside WoT runtime. For this case we considered all scripts to be trusted and provisioned to a device by a single trusted entity (for example by a device flashing).
WoT Servient Single-Tenant
Since all scripts running inside the WoT 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 it is based on the restricting the API exposed to the scripts running within the WoT Runtime. The exact set of guarantees depends on a concrete WoT Runtime implementation and might vary.
Native OS process-based isolation. This method relies on the underneath 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 to be used.
Native OS advanced isolation. A native 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 (see Section for more details on how to evaluate the risk level). 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 the token-based authentication methods. However, there are no methods in the WoT Scripting API to perform any such tasks, but 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 & 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 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 metadata to be provisioned and made accessible for its scripts. This metadata should be also strictly isolated between different tenants.
Fill in the isolation recommendations when we understand how security metadata is stored and made accessible to scripts
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.
Terminology
Please refer to the WoT Architecture document for terminology definitions.
