IoT Security

Securing Building Connectivity at Wattsense

Communication over the existing Internet infrastructure plays an important role in providing value-added services to our customers. Each Wattsense Box connects to our IoT platform using 4G or other means of Internet connectivity to send and receive data. This type of bi-directional and real-time communication is challenging to secure and requires great emphasis over data security and privacy. At Wattsense, offering a secure network connection to our users is crucial, and various measures have been taken to ensure enterprise-grade security and privacy across different domains. In this article, we introduce some key concepts to explain our robust security model and how we ensure that data is protected from any attacks.

The Architecture

There are two main communication paradigms for the Wattsense Box and IoT platform where data is sent or received over the Internet and stored at the IoT platform. These include Box to IoT Platform and IoT Platform to users. In the following, we discuss various design principles and strategies employed by us to provide end-to-end data security and privacy for our Boxes and IoT Platform.

ArchitectureAn overview of the communication paradigms at Wattsense

Box to IoT Platform

The main communication workflow between the Box and the IoT platform is as follows: the Box sends data points and events while the IoT platform sends configurations and commands to the Box. The following strategies are employed to ensure the security of data in transit.

1 - End-to-End Encryption

The encryption process takes care of encoding a message or information so that only authorised entities can access it. Transportation Layer Security (TLS) is an industry-standard communication layer for sending encrypted data over a wide area network. The TLS connection is initiated by a secure key exchange, symmetric encryption, and message integrity checks. At Wattsense, all our communication, especially Box to IoT platform is over TLS and follows the three main properties:

  • Communication is private, and nobody can spy on the content of the exchange.

  • The integrity of the communication is guaranteed, and nobody can modify the content of data transferred between the Box and the IoT platform.

  • The identities of both the Box and the IoT platform is authenticated.

To secure the communication between the Box and our IoT Platform, we use TLS with both server authentication (default) and client authentication mode. That is, the Box makes sure that it is connected to the IoT platform owned by Wattsense, and our IoT platform makes sure that the Box that connects is authentic and provided by Wattsense. To achieve this, the Box uses the Certificate Authority (CA) to validate that the IoT platform it is connecting to is owned and run by Wattsense, while the IoT platform uses uniquely generated certificates by Wattsense to validate the Box’s identity, these certificates are generated and securely stored at our IoT platform. Such an authentication mechanism adds multiple security layers and prevents any spoofing or man in the middle attacks.

By default, our Boxes connect via 4G to the service, reducing the scope of potential attacks.

WorkflowA communication workflow between the Box and IoT Platform
2 - Publish/Subscribe Model

The publish/subscribe paradigm enables a secure workflow to connect remote Boxes with the IoT platform while communicating over a set of defined channels or topics.

As described earlier, each Box has a uniquely generated certificate to authorize the communication with the IoT platform. The IoT Platform relies on these certificates to authorize the Box to exchange data with the server using its private communication channels. Hence, in case the certificate of a Box is compromised, we can revoke the access to these channels by revoking the certificate.

3 - Outbound-port-only Design Pattern

Leaving inbound ports open may lead to potential attacks on the software using the said ports, which can cause malware infections, the modification, and theft of data, DoS attacks, and arbitrary code execution. Considering this, Wattsense Boxes follows an outbound-port-only design pattern owing to the publish/subscribe model.It protects against the attacks described above. Therefore, the Box communicates with the outside world rather than external communications being sent to specific Box ports.

4 - Box Status Monitoring

The presence of anomalies in the Box connection and data sent to the IoT platform may indicate the presence of a security incident. At Wattsense, we actively monitor the status of our Boxes: an offline device could mean local tampering is taking place. In this case, we actively communicate with our customers to determine the nature of such incidents and to provide support if needed.

5 - Secure Firmware and Software Updates

A major requirement for an efficient security model is to keep the Box software and firmware up-to-date correctly. At Wattsense, we employ an enterprise-grade platform to update Boxes over the Air (OTA) by means of encrypted channels securely. Our platform comes with features such as constraining software deployment to a specific set of Boxes, cascading deployments, emergency stops to software roll-outs in case of failure and breaches. Moreover, we also use state-of-the-art software integrity checks, e.g., checksums of software binaries, to ensure the authenticity of existing or updated firmware and software.

IoT Platform to Users/Applications

The aim of the communication between the IoT platform and the user (or applications) is to either retrieve data sent from the Wattsense Boxes, to configure the Box or send commands to the Box. The data from the Boxes are securely stored in our cloud and is exposed by various APIs.

Communication

We provide two means of single/bi-directional communication between users and our IoT platform.

1 - REST API

A REST API can be used for manipulating and managing the resources on our IoT platform. To provide secure communication, our REST API is only accessible over HTTPS (HTTP over TLS). That is, the data is sent and received over a secure and encrypted channel. The authentication and authorisation practices for our REST API are described as follows.

  • Authentication:

    The two main types of authentication for REST API are Basic Auth and API Keys. Since securing authentication credentials in plain text is quite risky, we employ irreversible hashing and brute-force resistant algorithms to store it securely. Moreover, each API request on our IoT platform comes with authentication credentials (Basic Authentication or API Keys) and is validated on the server for every request.

    In the upcoming release, we will allow two-factor authentication to further fortify access to our REST API. (*)

  • Authorisation Model:

    Our REST API also provides a resource level authorisation model for controlled access to each resource. For example, an admin can allow a user to send commands to a specific Box or read data without finding out the private Box configuration. Our authorisation model follows the following two main principles to ensure privacy and security:
    - A user/application should only have the required set of permissions to perform the actions for which they are authorised, and no more.
    - A user’s default access level to any resource should be “denied” unless it has been granted explicit permission.

    On our IoT platform, every user is linked to an Account, and can only see what the administrator has allowed him to access. This enables Box owners to customise access for application developers, using custom or default roles, and to maintain privacy to the highest standards.

2 - MQTT and Webhooks

The MQTT and Webhook connectors for our IoT platforms are mostly used to get data in a real-time manner.

The MQTT connector provides two modes of secure communication over encrypted channels:

  • Basic Authentication:

    Basic Authentication uses the provided credentials of the remote MQTT broker and opens a secure channel [over TLS] to send data and received property commands

  • Certificate Authentication (X.509 certificates):

    This uses a certificate-based authentication that adds a further strict requirement of validating our connector’s identity.

Webhooks send the data from our IoT platform to remotely configured client’s servers. The provenance of the client’s servers is configured using our REST API. Webhooks communication also uses HTTPS and includes Basic Authentication and OAuth authentication.

To make sure that the communication between Wattsense and your endpoints is not compromised, we create a hash signature (using HMAC hex digest) with each sent data Item and send it along with the original data. This enables our customer to determine that the message received is not compromised and is the one sent by Wattsense.

Data Storage Isolation

Data storage and access on our IoT platform apply best practices and adhere to industry standards to provide comprehensive security protection.

The servers that host our database are located in a unique Virtual Private Cloud (VPC) with dedicated firewalls. Hence, our databases are hidden from the Internet, and only the services within the authorized VPC networks (through VPC Peering) are allowed to access it.

NetworkNetwork Isolation between the database and IoT Platform’s services

(*) The two-factor authentication will be available by Q4 2020

Ready to get started?
Create an account or get in touch.