Related W3C Documents

For a general discussion of best practices for developing secure WoT Systems, as well as a set of suggested combinations of authentication mechanisms and secured protocols, see the WoT Security Best Practices document.

For detailed Web of Things specifications, please refer to the following:

• the [[WoT-Usecases]] document,
• the [[WoT-Architecture11]] document,
• the [[WoT-Thing-Description11]] document,
• the [[WoT-Discovery]] document,
• the [[WoT-Binding-Templates]] document, and
• the [[WoT-Scripting-API]] document.

Other information on the Web of Things can be found on the WoT web site at https://www.w3.org/WoT/.

Document Outline

The rest of this document is structured as follows:

• Section [[[#wot-device-lifecycle]]] first explains the process by which things are incorporated into a WoT system and the security-related considerations that go along with it.
• Section [[[#analysis]]] then derives a number of security-related requirements from these considerations and formulates a Threat Model, illustrated by three different scenarios.
• Section [[[#wot-privacy]]] elaborates on privacy considerations and provides specific guidelines and recommendations.
• Security aspects related to onboarding are discussed in section [[[#security-provisioning-onboarding-and-maintenance]]].
• Section [[[#references-to-existing-security-best-practices]]] conducts a review of existing security best practices.
• Possible mitigations for the threats previously described are presented in section [[[#security-mitigations]]].
• Section [[[#examples-of-wot-security-configurations]]] gives a number of examples for security configurations in different scenarios.
• Finally, section [[[#e-security-validation]]] provides guidance for testing and the evaluation of security and privacy considerations.
• Additional terminology used throughout the document is introduced in section [[[#e-terminology]]].

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 WoT 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.

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.

The main execution boundaries for WoT System are:

Boundary	Description	Notes
Script Execution Boundary	Separates execution contexts between different Exposed Things. 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.

Out of above execution boundaries, the following ones become in-scope attack surfaces for the WoT security model only 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:

System Element	Compromise Type(s)	Assets Exposed	Attack Method
Script Execution Boundary	Modification or unauthorized access to any asset available to other scripts. Denial of Service	TDs, System User Data, WoT Thing Resources, WoT Infrastructure Resources, WoT Controlled Environment	Local attack by an untrusted WoT script using WoT Scripting API or any native OS local method.
WoT Runtime Instance Execution Boundary	Modification or unauthorized access to any asset available to another WoT Runtime running on the same HW device. Denial of Service	TDs, System User Data, WoT Thing Resources, WoT Infrastructure Resources, WoT Controlled Environment	Local attack by an untrusted WoT runtime using any native OS local method.

While the WoT Execution Boundary is the main boundary between the WoT layer and the rest of the software on a given physical device, we don't consider it as in-scope attack surface for this threat model, because we are not able to define security measures that prevent lower layers of device's software stack to access and compromise the WoT runtime and Protocol Bindings. Such measures would greatly depend on underlying device implementation and should be considered by an OEM that produces physical device and enables it for WoT usage. Similar the WoT Runtime and Protocol Bindings Execution Boundariesare out of scope, because their presence and implementation depends on concrete architecture of WoT runtime.

In addition to attack surfaces related to the execution boundaries within a physical device, the following network-facing interfaces are in-scope attack surfaces for this threat model:

System Element	Compromise Type(s)	Assets Exposed	Attack Method
WoT Interface	Modification or unauthorized access to any affected asset, Unauthorized execution of exposed WoT Interfaces, Denial of Service	TDs, System User Data, WoT Thing Resources, WoT Infrastructure Resources, WoT Controlled Environment, WoT Behavior Metrics	Network attack
WoT Protocol Bindings	Modification or unauthorized access to any affected asset, Unauthorized execution of exposed WoT Protocol Bindings, Denial of Service	System User Data, WoT Thing Resources, WoT Infrastructure Resources, WoT Controlled Environment, WoT Behavior Metrics	Network attack

If a WoT System allows dynamic installation of scripts inside WoT runtime, the following attack surfaces are added:

System Element	Compromise Type(s)	Assets exposed	Attack Method
WoT Script Management Interface. This interface, likely in practice implemented by a manager Thing (or Thing Manager), allows dynamic installation, removal and update of WoT scripts.	Compromise of WoT scripts, including installing an older version of legitimate scripts (rollback)	System Provider Scripts (part of System Provider Data) and their execution environment	Network attack

The following attack surfaces are currently out-of-scope for the WoT Security model:

System Element	Compromise Type(s)	Assets Exposed	Attack Method	Reasoning
Thing Directory	Modification or unauthorized access to hosted TDs, Denial of Service by preventing legitimate users from obtaining TDs, Inference of non-public or privacy sensitive information based on the observation of the protocol between the WoT endpoints and Things Directory.	TDs, history of interaction with Thing Directory	Any remote or local attack method on a Thing Directory service that results in attacker obtaining unauthorized access or the ability to modify TDs hosted by this service or to cause any type of DoS attack on the hosting service itself. In addition public hosting of TDs by a Thing Directory can have strong privacy implications and risks, as well as obtaining information on interactions between the Thing Directory and a given WoT System 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.
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	Device compromise on all SW or HW levels below WoT Runtime.	Any type of the WoT assets	Any remote or local attack method on WoT Devices 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.

Security Scenarios

Here we describe some typical high-level WoT scenarios and give practical examples of the above threats for each scenario.

Goals and requirements

Following the lifecycle diagram , the purpose of the Security provisioning is that upon its completion a WoT Device is equipped with the security metadata and credentials it needs 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 [[RFC8576]] refers to this stage as "Bootstrapping".

The purpose of the Security maintenance is maintaining security level set during the security provisioning phase, i.e. security-related configuration updates, such as key rotation or certificate refresh. This also includes the actions to be taken in case of credential compromise, i.e. key revocation.

• Initial enablement. During manufacturing a device is provisioned with the necessary credentials that enable secure mutual authentication and remote attestation in the next step.
• Mutual trust establishment. Establishing mutual trust between the device to be provisioned and the provisioning entity. Note that the provisioning entity is not necessary (and quite commonly not) a manufacturer, but some service provider or service domain owner. This includes mutual authentication and authorization for both device and provisioning entity and potentially remote attestation of device.
• Runtime credential provisioning. The actual provisioning of credentials for the operational phase in a secure fashion between the provisioning entity and the device.
• WoT specific provisioning. Installing the provisioned secrets and made them available and ready to use on the WoT level (within the WoT Runtime)

Do we try to describe only the bootstrapping of the credentials into a WoT run time (after which it can be transparently used during operational phase) or do we go into describing of how credentials will end up in the physical device at the first place, and then how they can be securely retrieved and embedded into WoT run time?

Do we limit ourselves to the case of a single tenant (single security domain device joins and accepts credentials from a single provisioning entity) or we also take multiple tenants in the scope from beginning?

Existing approaches

I guess we dont want to consider old style approaches as "ask user to input manually smth" or "connect to manufacturer to fetch credentials via manufacturer service"?

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.

This recommendation helps prevent the following threats: WoT Communication Threat - TD Authenticity, WoT Communication Threat - TD Confidentiality and Privacy, Disclosing WoT Thing/Device configuration, Disclosing WoT System configuration, Tracking WoT System User.

Avoid Exposing Persistent Unique Identifiers

When defining fields exposed by a TD immutable information should 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.

This recommendation helps prevent the following threats: WoT Communication Threat - TD Confidentiality and Privacy, Disclosing WoT System configuration, Tracking WoT System User.

Minimize Publicly Exposed Information in TD

WoT TDs should minimize the amount of information that is publicly available about a WoT Thing. For example, the TD should generally not identify the version of the software or operating system a device is running, since this information can be used to identify vulnerable systems. Instead the TD should capture all information needed to support interoperability without reference to particular implementations.

This recommendation helps prevent the following threats: WoT Communication Threat - TD Confidentiality and Privacy, Disclosing WoT Thing/Device configuration, Disclosing WoT System configuration, Tracking WoT System User, WoT DoS Threat.

Limit TDs exposure

Limit clients who can obtain a certain TD (or its privacy-sensitive parts) via authentication and authorization methods. This can be done by exposing a number of TD variants for the same WoT Thing based on the level of client’s access. For example, versions of a TD for "public access" may be generated with a subset of information in the full TD, omitting (for example) support or version metadata.

This recommendation helps prevent the following threats: WoT Communication Threat - TD Confidentiality and Privacy, Disclosing WoT Thing/Device configuration, Tracking WoT System User, WoT DoS Threat.

Secure Practices for protecting System User Data

Use Secure Transports

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, HTTP-over-TLS (HTTPS), CoAP-over-DTLS (COAPS), and MQTT-over-TLS (MQTTS) should be used if any kind of authentication or secure access is required. If data travels over many intermediate nodes (potentially malicious or not privacy-preserving), end-to-end encryption methods should be preferred.

This recommendation helps prevent the following threats: WoT Communication Threat - System User Data Authenticity, WoT Communication Threat - System User Data Confidentiality and Privacy, Leaking WoT System User Data.

User Consent

Keep System Users informed about the information that can be exposed or collected about them. Provide a way for System Users to control the degree of such exposure.

This recommendation helps prevent the following threats: WoT Communication Threat - System User Data Confidentiality and Privacy, Leaking WoT System User Data.

Secure Practices for designing WoT Interfaces

Use Appropriate Access Control Schemes

Use Security Metadata options to configure appropriate authentication and authorization methods for WoT Interfaces exposed by a WoT Thing. Minimize the amount of WoT Interfaces without any access control defined (including emitting public events). Consider different levels of access for different users.

This recommendation helps prevent the following threats: WoT Interface Threat - Unauthorized WoT Interface Access, WoT Interface Threat - Exposed Thing Compromise, WoT Communication Threat - System User Data Authenticity, WoT Communication Threat - System User Data Confidentiality and Privacy, Leaking WoT System User Data, Disclosing WoT Thing/Device configuration, WoT DoS Threat.

Avoid Heavy Functional Processing without Authentication

When defining WoT Interfaces exposed by a TD, it is important to avoid any heavy functional processing before the successful authentication of a WoT Consumer. 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).

This recommendation helps prevent the following threats: WoT Interface Threat - Exposed Thing Compromise, WoT Interface Threat - Unauthorized WoT Interface Access, WoT DoS Threat.

Strong Validation and Fuzz Testing on All WoT Interfaces

All WoT Interfaces (and especially public ones) should be well-tested (including fuzz testing) and validated since they are a primary attack surface of a WoT Thing.

This recommendation helps prevent the following threats: WoT Interface Threat - Exposed Thing Compromise, WoT Interface Threat - Unauthorized WoT Interface Access, WoT DoS Threat.

Secure Practices for End-to-End security

The notion 'end-to-end' security (short: E2E security) is often encountered when security is considered. Quite often, this notion is encountered in a way that is misleading: it is a matter of risk assessment to determine the "ends" that are to be protected in a distributed system such as WoT (identifying the domain-of-protection) and then select one or more security technologies to fulfill the identified demand (not: vice versa).

In that sense, there is no single, universal notion of E2E security in WoT. There is also no single security technology that allows to deliver E2E security for any definition of the ends. The perception of WoT security is to support users of WoT in implementing security architectures according their perception of the ends (which can vary across users, deployments etc.) using for instance:

• CMS as well as XML/JSON/CBOR security (IETF resp. W3C) to provide E2E security on the level of application data
• (D)TLS (IETF) to provide E2E security between client and server processes
• IPsec (IETF) to provide E2E security between endpoints in an IP-based inter-network
• MACsec (IEEE) to provide E2E security between endpoints in one local network

The following technologies allow to address E2E security in the first sense (protecting exchanges between WoT system components on the level of application data):

• If authenticity is desired for exchanged application data, then sign WoT objects (TDs, system user data) using 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, [[RFC7515]] provides a guideline for expressing digital signatures or MACs as well as related security metadata using JSON-based data structures. [[RFC9052]] does the same for CBOR.
• If confidentiality is desired for exchanged application data, then encrypt WoT objects using well-known encryption primitives. For data expressed in JSON, [[RFC7516]] provides a guideline for expressing encrypted data as well as related security metadata using JSON-based data structures. [[RFC9052]] does the same for CBOR. Moreover the following is important here:
  • Confidentiality without authenticity (i.e. encryption-only) does not provide a secure scheme. Use authenticated encryption, not encryption-only to provide confidentiality
  • Classical cryptographic schemes (pre-AEAD, see [[RFC5116]]) cover encryption-only as well as authentication-only. This requires users of cryptographic schemes to create an own design to deliver authenticated encryption and this tends to go wrong. Use AEAD schemes to deliver authenticated encryption (or use an underlying security protocol such as (D)TLS – when this can fulfill the identified E2E security demand)

This recommendation helps prevent the following threats: WoT Communication Threat - System User Data Authenticity, WoT Communication Threat - System User Data Confidentiality and Privacy, Leaking WoT System User Data, WoT Communication Threat - TD Authenticity, WoT Communication Threat - TD Confidentiality and Privacy.

Basic Interaction between WoT Thing and WoT Consumer

shows the basic WoT Consumer (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 Interface and also directly provides a Thing Description. The Thing Description describes the interactions that can be performed on the WoT Thing.

From a security point of view two aspects are important to consider in this scenario. First, the WoT Consumer 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 Consumer must have a way to authenticate the device exposing the WoT Thing. Second, upon receiving requests from a WoT Consumer, the WoT Thing must verify the the WoT Consumer 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 Consumer 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 Consumer 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 Consumer 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 Consumer 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 Consumer has been provisioned with the certificate of the device exposing the WoT Thing (and visa 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 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 [[RFC7519]] 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 [[RFC8392]]. 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.

Suitable choices of the above security measures allows mitigation of the WoT Interface Threat - Unauthorized WoT Interface Access threat.

In addition to the above measures, authenticity, confidentiality and replay protection of transferred solution data and of TDs between the WoT Consumer and the WoT Thing is strongly recommended for scenarios where an attacker can observe or/and modify the traffic in the WoT System. While TD transfer might only require authenticity protection, the solution data itself usually requires protection of all its aspects. This helps to mitigate the following threats: WoT Communication Threat - TD Authenticity, WoT Communication Threat - TD Confidentiality and Privacy, WoT Communication Threat - System User Data Authenticity, WoT Communication Threat - System User Data Confidentiality and Privacy.

Authenticity, confidentiality and replay protection can be guaranteed by usage of secure transport protocols to exchange data between the WoT Consumer 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 for Constrained RESTful Environments (OSCORE) method described in [[RFC8613]].

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 Consumer 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.

The primary additional security consideration of this scenario is the need for the secure transfer of the TD between the WoT Consumer and the Thing Directory. The Thing Directory can reside in a Intermediary WoT Servient 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 Consumer 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 Consumer 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 [[RFC9052]]. This can be done by the provider of the Thing Description and verified by the WoT Consumer after the download from the remote cloud.

Interaction between WoT Thing and WoT Consumer via an Intermediary WoT Servient

A , as in the configuration, also allows a WoT Consumer to connect to and operate or monitor a WoT Thing. However in contrast to the basic (direct connection) case, the interaction between the WoT Consumer and the WoT Thing is now mediated by an Intermediary WoT Servient. The Intermediary WoT Servient 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 Intermediary WoT Servient is structurally identical to the one that would have been provided by the Thing directly, except for any necessary modifications to URLs, protocols used, and (perhaps) a modified security configuration.

From a security standpoint this case is quite similar to the one described in Section . The main difference is that mutual authentication should be established between all directly communicating parties, i.e. between the WoT Consumer and the Intermediary WoT Servient, as well as between the Intermediary WoT Servient and the device exposing the WoT Thing network interface. If there is no direct communication between the Intermediary WoT Servient 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 Intermediary WoT Servient device provides to the WoT Consumer 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 Intermediary WoT Servient. It is also possible that the end device behind the Intermediary WoT Servient 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 Intermediary WoT Servient has to build the Thing Description by itself i and expose it to the WoT Consumer. For all typical use cases, the Intermediary WoT Servient 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 Intermediary WoT Servient 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 Intermediary WoT Servient, but can be fetched by the WoT Consumer 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 Intermediary WoT Servient. 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 Consumer 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.

Basic Interaction between WoT Thing and WoT Consumer 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 Consumer cannot contact the WoT Thing directly. In the configuration shown here the communication between the WoT Consumer and the WoT Thing is handled via a pair of Intermediary WoT Servients: one residing in the local protected network, known as the Local Intermediary WoT Servient, and another running in the cloud, known as the Remote Intermediary WoT Servient. 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 Intermediary WoT 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 Intermediary WoT Servient only communicates over this channel with the Remote Intermediary WoT Servient. The WoT Remote Intermediary WoT Servient should use the mechanisms described in Section in order to authenticate and authorize the WoT Consumer 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 Consumer and the Remote Intermediary WoT Servient. If the WoT Consumer is authorized, then the Remote Intermediary WoT Servient can package the WoT request and transfer it over the secure channel to the Local Intermediary WoT Servient, which in turn can issue requests to the WoT Thing on the local network. The local network channel between the Local Intermediary WoT 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 Intermediary WoT Servient), as well as to provide confidentiality and integrity of transferred solution data and the TD.

An alternative security setup for this scenario can use end-to-end security authentication and authorization. In this case the WoT Consumer would not only need to authenticate and authorize itself to the Remote Intermediary WoT 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 Consumer 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 .

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 Consumer, assuming a secure protocol stack such as HTTP-over-TLS 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 HTTP-over-TLS (HTTPS) network interface. In this case, the tunnel should be encrypted (for example, using SSH) to prevent eavesdropping; a regular IP tunnel is not sufficient. Depending on the configuration, the unencrypted traffic (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 interface is not desirable, another SSH tunnel can be used between the WoT Thing and the Intermediary WoT Servient, 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 [[RFC9052]].

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.

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 [[RFC9052]]. 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 an Intermediary WoT Servient) 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).

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 Consumer 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 Consumer 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".

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.

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.

The case of the multi-tenant servient with a possibility to install WoT Scripts remotely into WoT Runtimes brings an additional set of threats that must be taken into account: WoT Script Management Interface Threat, WoT Untrusted Script Threat - Script Compromise, WoT Untrusted Script Threat - Runtime Compromise, WoT Untrusted Script Threat - Authenticity, WoT Untrusted Script Threat - Confidentiality, WoT Untrusted Script Threat - TD Authenticity, WoT Untrusted Script Threat - TD Confidentiality and Privacy, WoT Untrusted Script Threat - System User Data Authenticity, WoT Untrusted Script Threat - System User Data Confidentiality and Privacy, and WoT Untrusted Script Threat - DoS.

In order to address these threats one should utilize the strongest isolation method available on the device to separate different WoT Runtimes. The isolation should cover execution context, runtime memory, local storage and resource allocation between different WoT Runtimes.

In addition the Thing Manager should have a reliable way to distinguish between different tenants in order to securely manage provisioning and updates of scripts into the corresponding WoT Runtime. This can be achieved by authenticating the tenant using one of the authentication methods described in Section .

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.

Testing Goals

The goal of WoT security testing is to find security vulnerabilities in the implementation of WoT components, so they can be mitigated. This can be broadened to finding weaknesses (potential vulnerabilities) since mitigating both actual and potential vulnerabilities is sufficient to secure a system, and in general it can be hard to determine if a weakness is exploitable. It is not possible in general to prove the converse, that a WoT component is secure (that is, that it has no vulnerabilities). However, thorough security testing can at least ensure that there are no obvious (easily discoverable) weaknesses or vulnerabilities in an implementation.

Furthermore, the goal of security testing for an implementor is to identify the existence of weaknesses, not to exploit them to break into or manipulate a system. For an implementor, the priority after discovery of a weakness is to implement a mitigation to prevent it from being exploited, not to actually find or create an exploit and use it. Not all weaknesses are vulnerabilities. Fixing actual (exploitable) vulnerabilities should have a higher priority than simple weaknesses, so an implementor may want to also determine which weaknesses are exploitable in order to prioritize mitigations.

In the following we provide some background on testing, including a description of several varieties of security testing and examples of suitable tools for each. While we provide some tool examples in the following, they are just examples; you are free to use any tool that fits the purpose. After introducing the categories of testing and examples of tools for each, we then present a general security testing plan for WoT Systems based on these categories.

Best Practices

Before beginning security testing, it is useful to determine if the components of the system being tested have been implemented following good and up-to-date security practices. What we really want to do is identify systems that use known insecure practices, for which vulnerabilities are known. Many times such vulnerabilities will be obvious from the WoT Thing Description, and can be identified with simple tools.

As an example, suppose a WoT Thing combines "basic" authentication with plain (unencrypted) HTTP. In this case the username and password can be easily recovered from the header information of the unencrypted HTTP request by an eavesdropper with access to the network traffic, for example by code running in a compromised router or by someone who has broken WiFi encryption.

As another example, an older device may use an obsolete form of encryption for which an attack is known.

Hiding the Thing Descriptions of such systems is not really a solution: this is equivalent to security by obscurity which is widely considered to be ineffective. Generally, the "secret information" allowing access to a system should be in the form of easily modifiable keys, not engineering details which, once revealed, cannot be easily changed. However, certainly mitigating obvious vulnerabilities easily discoverable in the Thing Description should be a high priority. Ideally mitigation is accomplished by modifying the implementation but this is not possible in all cases. If the implementation cannot be modified it may be possible to achieve partial mitigation by securing the network environment, e.g. by using a VPN or encrypted tunnels to encapsulate the vulnerable network traffic.

Another point to note is that a Thing Description may not describe all the network interfaces of a Thing. A Thing may have a Thing Description that describes a network interface that follows best practices and may pass all the additional security tests described below on that interface, but may still have an insecure backdoor (additional network interface) not described in the Thing Description. It is the implementor's responsibility to secure all network interfaces, even if the Thing Description is subsetted. Note that there are valid reasons to subset a Thing Description, for example to provide different interfaces to users with different roles and access rights.

A WoT System may also have infrastructure components that do not have Thing Descriptions. There may, for example, be services such as proxies or directories. These should also be tested. If they are web services or otherwise have documented network interfaces, then much of the testing procedure described below should also apply to them.

Functional Security Testing

Functional testing checks that a WoT Thing implements the interactions described in its Thing Description. This includes whether or not it responds to all URLs given and accepts and returns data as specified in the data schemas given in the Thing Description for each interaction.

Functional testing should also check that all security mechanisms described in the Thing Description are implemented properly. Does the Thing do what the Thing Description says it does in terms of security, and only that? Does the Thing Description accurately describe the security mechanisms used by the Thing? Do all interactions accept authorized accesses, and reject accesses that do not provide correct authentication and authorization information?

Again, there can be both purpose-built and pre-existing devices described by a Thing Description. A Thing Description needs to accurately describe the security behavior and requirements in both cases.

Adversarial Security Testing

Adversarial security testing (also known as penetration testing or pentesting) includes various checks that can be done in order to find weaknesses in the target device or service and determine their severity and exploitability (that is, whether they are actual vulnerabilities). On a high level adversarial testing consists of three stages, which are often applied iteratively:

1. Information gathering: Required information is collected about the attack target.
2. Weakness discovery: An attack target is analyzed and weaknesses are found.
3. Exploitation generation: An attempt is made to convert weaknesses into vulnerabilities by discovering or designing exploits.

Exploits are designed to achieve a desired outcome, such as privilege escalation, authorization bypass, denial of service, and other goals. A successful exploit of one vulnerability may be used to expose other weaknesses and allow them in turn to be exploitable. Conversely, a weakness may be prevented from exploitation by a mitigation that prevents the class of exploit to which it is vulnerable.

Many resources and tools exist to help penetration and security testers to perform the above activities. Many documents and tutorials have also been written to help guide this activity. One example of such guide is the "Web Service Security Testing Cheat Sheet" [[Owa18]] written by the Open Web Application Security Project (OWASP). Generally speaking, WoT components can be treated as web services for the purposes of security testing, especially if they use HTTP. However, WoT components also have some additional considerations, for example local access while using HTTP-over-TLS (HTTPS), or use of non-HTTP protocols such as CoAP or MQTT.

For the purposes of WoT security testing we will focus on Stage 2, Weakness Discovery. Weakness discovery can be broken down into a combination of static weakness discovery and runtime weakness discovery.

Stage 1 is not really necessary in the case of white-box testing, which we will assume (given that, for example, a Thing Description already documents much of the information needed). Generally speaking, trying to achieve security through obscurity is not feasible or desirable, so for testing we should assume the attacker knows as much about the system as the implementor. Also, since our goal is to test the security of the components of a WoT System, not actually break into it, we also will not focus on Stage 3. However, an exploitable vulnerability has a higher priority for correction than a simple weakness for which no exploit is (yet) known, so this information is still useful to prioritize mitigation.

Security Testing Plan Framework

Given the above background, we can now outline a testing plan framework for WoT Systems. This is just an outline and would have to be expanded and adapted for the specific circumstances and application area of the WoT System under test. In particular, some tool choices may depend on the programming language, build environment, network environment, and budget (for non-free tools). Also the testing procedure will be different for purpose-built devices and services vs. pre-existing devices and services.

1. Static Weakness Discovery
   1. Static Code Analysis: If source code is available, a static code checker should be used to check for weaknesses in new purpose-written code.
   2. Known Vulnerability Checking: If binaries and/or a list of package dependencies are available, a vulnerability checker should be used to check for known weaknesses and vulnerabilities in any libraries used.
2. Runtime Weakness Discovery appropriate tools such as Fuzz Testing, Protocol Analysis, and Vulnerability Scanners can be discover problems even when only the network interface is available, and are complementary to other kinds of checks.
3. Exploitation Analysis This can be used to prioritize which weaknesses and vulnerabilities should be addressed first or whether a given vulnerable system can even be used in a given environment.

Ideally, security testing should be integrated into the development process and all discovered weaknesses addressed as soon as possible. If this is not possible, weaknesses should be prioritized based on the threat model and potential for exploitation and addressed in priority order.

Suggested Testing Frequency

The actual detailed test procedure depends on the type of activity, the WoT device setup and the actual test tool used. However, below are our general recommendations for the frequency of different testing activities:

1. Static Weakness Discovery should be done regularly, ideally integrated into the development work flow for a WoT component. This is important, since any even small code changes can introduce development mistakes, or alternatively new weaknesses can be discovered in the libraries that a program depends on. New weaknesses and vulnerabilities are discovered in existing libraries almost daily.
2. Runtime Weakness Discovery should be also done on a regular basis, for example for each major release or development milestone.
3. Exploitation Analysis should be done occasionally, whenever possible. It is the most time and resource consuming activity, often requires external resources with specialized knowledge, and cannot in general be automated.

Summary

A security testing plan focused on weakness and vulnerability discovery has been presented that leverages existing tools and approaches for web services and emerging tools for new IoT-oriented network interfaces. A testing plan should be developed suitable for each system developed using the WoT Architecture but will generally consist of three stages: static weakness discovery, runtime weakness discovery, and Exploitation Analysis. A vulnerability is a weakness with a known exploit and should have priority for mitigation, but all weaknesses may potentially lead to vulnerabilities and ideally all weaknesses would be mitigated or corrected. In general, a WoT Thing Description can be used to describe both secure and insecure systems, and in fact this is necessary to support existing devices, which may or may not themselves be intrinsically secure. However, WoT Thing Descriptions provide new opportunities for understanding and planning security testing and mitigations.