DEV Community

Beck_Moulton
Beck_Moulton

Posted on

Securing IoT Data Integrity with Go IoT Platform

Translation:

Go IoT Development Platform is a free, efficient, and scalable Internet of Things (IoT) solution developed using the Go programming language. The platform supports data transmission protocols such as MQTT, HTTP, WebSocket, COAP, and TCP/IP, and provides lightweight configuration tools for alarm functions and data statistics services based on JavaScript.

Official Website: http://iot-dev-egi.pages.dev/

Repository Address: https://github.com/iot-ecology/go-iot-platform

We are looking for React development engineers; your participation is welcome.

Event Description

EMQX can receive second-level data reports from many devices at any time, but this may not conform to the normal business process. For example, under normal circumstances, a device may report data once every 5 minutes. To identify whether the reporting device is legitimate, we need a method to detect whether the device might be a malicious device, deliberately reporting data frequently to affect the stability of EMQX.

Go IoT Development Platform's Solution

Physical Device Details: There are two key fields in the physical device details (DeviceInfo): Push Interval (seconds) and Push Time Error (seconds). With these two fields, we can determine whether the device's reporting behavior is abnormal and proceed with subsequent logical processing.

Calculation Method

To calculate whether the device's reporting rate is within the push interval and error, and whether it is outside the error, we first need to define some variables and conditions:

  1. The device's push interval is denoted as ( T ) (seconds).
  2. The device's push time error is denoted as ( E ) (seconds).
  3. The actual push interval of the device is denoted as ( T_{\text{actual}} ) (seconds).

0. Calculation of Actual Push Interval

  1. First Push Timestamp: The time when the device first pushed data ( T_{\text{1}} ).
  2. Second Push Timestamp: The time when the device pushed data for the second time ( T_{\text{2}} ).
  3. Actual Push Interval: ( T_{\text{actual}} = T_2 - T_1 )

1. Calculation of Whether Within Push Interval and Error

The device's rate is considered to be within the push interval and error if the actual push interval ( T_{\text{actual}} ) meets the following condition:
[ T - E \leq T_{\text{actual}} \leq T + E ]

2. Calculation of Whether Outside Error

The device's rate is considered to be outside the error if the actual push interval ( T_{\text{actual}} ) does not meet the above condition, i.e.:
[ T_{\text{actual}} < T - E \quad \text{or} \quad T_{\text{actual}} > T + E ]

Example Calculation

Assume:

  • Push interval ( T = 60 ) seconds
  • Push time error ( E = 5 ) seconds
  • The device sent the first data at 10:00:00 on September 20, 2024 (i.e., ( T_1 ))
  • The device sent the second data at 10:01:05 on September 20, 2024 (i.e., ( T_2 ))

Calculation of ( T_{\text{actual}} )

[ T_{\text{actual}} = (10:01:05 - 10:00:00) = 65 \text{ seconds} ]

Check Whether Within Push Interval and Error:

[ 60 - 5 \leq 65 \leq 60 + 5 ]
[ 55 \leq 65 \leq 65 ]
Since ( 55 \leq 65 \leq 65 ) holds true, the device's rate is within the push interval and error.

Check Whether Outside Error:

Since ( 65 ) is not less than ( 60 + 5 ), the device's rate is not outside the error.

By this method, you can accurately calculate the actual push interval of the device and further analyze whether it complies with the set push interval and error rules.

Problem Handling

By the calculation method mentioned earlier, we can determine whether the reported data conforms to the expected push interval and error range. Generally, data that conforms to this range is considered normal and needs to be processed, while data beyond this range may be considered abnormal and should be discarded. In the Go IoT Development Platform, for such abnormal data, we will take the following measures:

  1. Data Discarding: Directly discard data that exceeds the push interval and error range. When consuming messages in the message queue, directly ACK (Acknowledge) these data without persistent storage.

  2. Maintenance through EMQX server management tools

1. Exclude Clients through EMQX's Blacklist

Using EMQX's blacklist feature, we can restrict malicious or abnormal reporting clients. Here is a detailed analysis of the advantages and disadvantages of disabling objects and their use cases:

Disabled Object Advantages Disadvantages Use Cases
Client ID - High precision, can directly restrict specific clients.
- Easy to implement, usually the client ID is unique, easy to manage and track.
- If the client changes the ID, it needs to be added to the blacklist again.
- A mechanism is required to identify and record the client ID.
- Suitable for scenarios requiring precise control of individual devices or clients.
- When it is easy to identify and record the MQTT client ID of the reporting device.
Username - Can manage a group of devices using the same username.
- Simplifies the management of a group of devices.
- Not suitable for scenarios requiring precise control of individual devices.
- If devices share a username, legitimate devices may be incorrectly restricted.
- Suitable for scenarios where devices use the same account password in batches or according to rules.
- When device management is more centralized and fine-grained control of individual devices is not required.
IP Address - Can quickly restrict all requests from a specific IP address.
- Simple and effective for devices with fixed IP addresses.
- Not effective for dynamic IP or mobile devices.
- May mistakenly restrict other legitimate devices under the same IP.
- Suitable for scenarios where devices have fixed IP addresses.
- When you need to quickly restrict traffic from a specific IP and there are no other legitimate devices under that IP.

The above three should prioritize Client ID first.

2. Exclude Clients through EMQX's Provided API Interface

EMQX provides an API interface that allows administrators to remove specific MQTT clients from the server. It should be noted that if the MQTT client has implemented a reconnection mechanism, simply removing it may not completely remove the client.

Reference: EMQX Documentation - Client Exclusion

Top comments (0)