Tag Archives: trust monitoring

IoTrust Architecture

The IoTrust framework is designed by keeping security and innovation at the core. It consists of 7 main components as shown in the figure above. Each components is developed to handle specific set of tasks in the framework. The fundamental features of IoTrust project are secure bootstrapping, over the air firmware update and trust monitoring. All other services are built around these features. The IoTrust components are following.

End-Device

It is a small form-factor hardware which sits on the edge of an IoT network. It consists of microcontroller, memory, input/output peripherals, communication modules etc. In the IoTrust architecture, an End-Device will be used to collect, format, and send sensor data to a server. The End-Device shall incorporate at least a LoRaWAN capable module to guarantee a set networking of features.

Gateway

A Gateway provides last-mile LoRaWAN radio access to the end-devices. It is an edge component at the end of the LoRaWAN network infrastructure. A gateway is a multi-channel high performance LoRa transceiver module that can receive, process, and send several LoRa packets simultaneously using different spreading factors on various channels. Communications’ security is provided through the LoRaWAN message encryption, as defined by the protocol specification. This scheme is employed in communications to and from the End-Device and the Network Server.

Network Server

The Network Server is part of the LoRaWAN back-end infrastructure. It represents the central hub of all communications from and to LoRaWAN end-devices. It aims to hide the Physical (PHY) and Medium Access Control (MAC) layer details of the LoRaWAN protocol to the components that need to communicate with end-devices. The Network Server will manage all the low-level details to guarantee secure and reliable delivery of messages to and from the LoRaWAN infrastructure.

IoT Controller

The IoT Controller plays the role of authenticator in the Authentication, Authorisation, and Accounting (AAA) architecture. The End-devices perform the bootstrapping process. This process includes an authentication and key agreement stage. Once the device successfully authenticates itself, session keys are shared with the device in order to securely perform the regular operation tasks.

Authentication Server

The AAA architecture has been proposed by standardisation organisation, such as IETF, to provide a scalable solution to security management tasks in heterogeneous IoT ecosystems, especially those employing long-range wide-area networks. The authentication server employs EAP, a flexible solution that supports several methods, with various degrees of performance
requirements for each End-Device.

IoT Agent

The IoT Agent is a MQTT client which subscribes to the topics exposed by the MQTT broker running in the Network Server. At the heart of MQTT are the MQTT broker and clients. The data sent by the end-devices is received by the Network Server over LoRaWAN, which is in turn dispatched using MQTT messages. Each message is posted in a device-specific application reception topic. IoT Agent forwards the device metadata and sensor data to the asvin platform. It does it over HTTPs using REST API end-points. The IoT Agent acts as a bridge between the Network Server and the asvin Platform

asvin Platform

It is a Platform as a Service (PaaS) to facilitate over the air security patches for IoT devices using novel decentralized and distributed technologies. The asvin Platform provides a complete solution for device, security patches and rollout management. It is comprised of 4 components.

  1. IPFS
  2. Blockchain
  3. Customer Platform
  4. Version Controller