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.
There are three 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, IoT Platform to users and direct Box to users communication. In the following, we discuss various design principles and strategies that are employed by us to provide end-to-end data security and privacy for our Boxes and IoT Platform.
Box to IoT Platform
The main communication workflow between the Box and the IoT platform is as follows: the Box sends 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.
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 and is used by the likes of Amazon Web Services, Google Cloud, online banks, etc. 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 (*).
The TLS layer uses the Wattsense Certificate Authority (CA) to validate the provenance of our IoT platform for Boxes, hence avoiding DNS spoofing attacks. Furthermore, it prevents message alterations in the case of Man-in-the-middle (MITM) attacks. By default, our Boxes connect via 4G to the service, making it even harder for a MITM attack to take place. (*)
The publish/subscribe paradigm enables a secure workflow to connect remote Boxes with the IoT platform. When the Wattsense Box is turned on, a new TLS connection is initiated with the IoT platform (remote server) and its existence is announced. The server first uses programmed hardware Ids and security credentials to determine if a Box is authorised to send data and receive commands.
The server then creates dedicated private and secure channels for authenticated Watsense Boxes through which the server can communicate and to which Boxes can subscribe or publish. This workflow only allows Boxes with specific credentials to be connected to our IoT platform at a time. Furthermore, since each Box communicates on separate secure channels, we can easily filter or disable compromised Boxes. Currently, we use a secure Websocket protocol to enable the publish/subscribe model. In the coming release, we plan to migrate to the MQTT protocol (**).
The security risks of leaving inbound ports open include malware infections, the modification, and theft of data, DoS attacks, and arbitrary code execution. Considering this, Wattsense Boxes follow 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. Since all the inbound ports are closed, even the physical access to the Box does not allow attackers to compromise the Box.
The presence of anomalies in the Box connection and data sent to the IoT platform may indicate the presence ofty 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 a securiactively communicate with our customers to determine the nature of such incidents and to provide support if needed.
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.
We provide three means of single/bi-directional communication between users and our IoT platform.
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.
The two main types of authentication for REST API are Basic Auth and API Keys (Tokens). Since securing authentication credentials in plain text is quite risky, we employ irreversible hashing and brute-force resistant algorithm 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. (***)
Our REST API also provides a resource level authorisation model for controlled access to each resource. For example, an admin can only 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.
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 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 server certificates. This is a standard way of secure communication for MQTT and is also deployed by Amazon Web Services, Google Cloud, etc.
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 customers to determine that the message received is not compromised and is the one sent by Wattsense.
Data Storage and Access
Data storage and access on our IoT platform apply best practices and adhere to industry standards to provide comprehensive security protection.
Access to stored data is controlled through carefully outlined user roles. Hence our customers can create rules to control which users and teams can access, manipulate, and delete data at each Box level.
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 dedicated services with defined IP addresses (VPC Peering) and operating within a private network are allowed to read and write data.
All our traffic generated within and outside VPC is encrypted over TLS. This provides all the attributes of secure data transfers, as described previously, for end-to-end encryption.
Data pseudo-anonymisation is a process of encoded pseudonyms in the identifying fields within a data record. This enhances the privacy of the collected data and is highly encouraged by the General Data Protection Regulation (GDPR) law put forward by the European Union (EU). All our data collected from the Wattsense Boxes follow this practice and data can no longer be attributed to a specific physical Box or organisation without the use of additional information.
Direct Box To User Communication
Some of our customers can directly connect to Wattsense Box and collect data. Since such a connection is also shared over the Internet, all the security measures mentioned above also apply to this communication paradigm. That is, the communication is End-to-End encrypted over TLS, and only dedicated outbound ports are open for a publish/subscribe communication model.
In this communication paradigm, the data is not sent or stored on our IoT platform, and the customers are responsible for the storage and access to their data. However, Wattsense Box can keep some data in its cache in case of a lost connection. This means there can be a risk of theft and tampering of the data stored in the Box. The following countermeasures are implemented to satisfy the security of the direct data access on Wattsense Box.
The Box is inaccessible from any physical port, making it impossible for anyone to access the Box internals.
No data are persisted and the only in-memory cache is used. This means the data will be lost if someone tries to extract it from the physical memory.
(*) The authentication by certificate will be available by Q2 2020
(**) On-box MQTT protocol will be available by Q2 2020
(***) The two-factor authentication will be available by Q2 2020