Author | Zhang Xiaoming, Cao Kejian, Peng Guangming
Everything is a computer. Everything is connected.
1. Overview of IoT Security Risks and Security Standards
In recent years, IoT devices have become the focus of network attacks, as reflected in various security incidents. At a macro level, the diversity and scale of IoT devices are vast. Once high-risk vulnerabilities are discovered in widely used device models, they can easily be controlled on a large scale, forming botnets and causing incidents such as the widespread outages in the United States and Germany in 2016 (MIRAI virus). Telecom operators are extremely concerned about such risks, as the deployment volume of a single model of device can reach millions. At a micro level, due to the limited computing capabilities of IoT devices, it is difficult to implement complex security functions. Moreover, most devices are deployed in a decentralized manner without supervision, leading to a high risk of targeted breaches. APT attacks on specific IoT devices or systems can result in sensitive data leaks, property losses, or even personal injuries, such as attacks on network cameras, smart locks, and implantable medical devices. The widespread application of IoT has left many traditional industries lacking in cybersecurity awareness and experience, necessitating corresponding standards and guidelines.
Since 2018, China has successively released several IoT security standards: GB/T 37044-2018 “Information Security Technology – IoT Security Reference Model and General Requirements”, GB/T 36951-2018 “Information Security Technology – Security Technical Requirements for IoT Perception Terminal Applications”, GB/T 37024-2018 “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways”, GB/T 37025-2018 “Information Security Technology – Security Technical Requirements for IoT Data Transmission”, GB/T 37093-2018 “Information Security Technology – Security Requirements for Access Communication Networks of IoT Perception Layers”, GB/T 37714-2019 “Technical Requirements for Security Assessment of Data Transmission for Public Security IoT Perception Devices”, GB/T 38637-2020 “IoT – Access of Perception Control Devices – Part 1: General Requirements”, etc. These standards regulate IoT security from multiple aspects including security models, access security, data transmission security, and device security. Although there are currently not many IoT information systems and devices that fully comply with these standards, with the promotion of standards and increased industry supervision, it is believed that the overall security of IoT in China will see significant improvement, making it increasingly difficult and costly for hackers to launch attacks. One regret in the published IoT security standards is the lack of corresponding evaluation standards.
2. Interpretation of IoT Perception Terminal Security Standards and Testing Approaches
GB/T 36951-2018 “Information Security Technology – Security Technical Requirements for IoT Perception Terminal Applications” is a national standard drafted by the Beijing Information Security Testing Center, which regulates the security of IoT perception terminal applications from five aspects: physical security, access security, communication security, device security, and data security. This standard not only focuses on the security of perception terminals themselves but also involves the security of their deployment and application, making it an application and system-level standard. The standard divides the security requirements for perception terminals into basic requirements and enhanced requirements, and IoT systems with security level three or above must meet enhanced requirements.
The security framework for IoT perception terminals
1Definition of IoT Perception Terminals
IoT information systems typically consist of perception layer, network layer, and application layer. Perception terminals operate at the perception layer, mainly consisting of data acquisition modules, computing modules, and communication modules, supporting various communication methods (wired, wireless, near-field, far-field, etc.) to adapt to different application scenarios. When in use, perception terminals can communicate with the application layer via local gateways or directly connect to the application layer through long-distance communication.
Example of IoT Information System
The standard defines IoT perception terminals as “devices that can collect information about objects or environments and/or perform operations, and can communicate over the network”. From the definition, perception terminals not only include conventional information collection devices but also encompass at least some control devices. From a certain perspective, process layer devices in industrial control systems, such as intelligent execution terminals and network-enabled variable frequency drives, are also included. The “IoT Security Standardization White Paper” published by the Information Security Standardization Committee in 2019 directly quoted the term “perception and control devices”, and the standard GB/T 38637-2020 “IoT – Access of Perception Control Devices – Part 1: General Requirements” adopted the term “perception control devices”.
2Physical Security
The standard regulates the hardware characteristics and security deployment of perception terminals from four aspects: model selection, site selection, power supply, anti-theft, and anti-damage. Since this article mainly focuses on the security testing of IoT perception terminals themselves, the deployment and application aspects will not be detailed here.
3Access Security
5.2.1 Network Access Authentication regulates the security of perception terminals accessing the perception network or IoT platform. Among them, 5.2.1 a) “Should have a unique network identity in the access network” is a basic requirement. Regardless of whether the perception terminal is accessing the network or communicating later, it should have a unique identity to allow the gateway or platform to identify its identity and audit its behavior. The network identity can be the terminal’s MAC address (Ethernet, WIFI, ZigBee, etc.), DevEUI (LoRaWAN), IMSI (3G/4G, NB-IoT), or an ID assigned to the terminal by the IoT platform, such as Alibaba Cloud ID² or Tencent Cloud IoT TID.
Regarding 5.2.1 b) “Should be able to prove its network identity to the access network and support at least one of the following identity authentication mechanisms:
(1) Authentication based on network identity;
(2) Authentication based on MAC address;
(3) Authentication based on communication protocols;
(4) Authentication based on communication ports;
(5) Authentication based on symmetric cryptography;
(6) Authentication based on asymmetric cryptography.
The purpose of access authentication is to ensure that only legitimate terminals/authorized users can access the IoT system. It requires perception terminals to support the access authentication protocols used by the gateway (or IoT platform) or at least be able to prove their network identity to the gateway (or IoT platform).
Perception networks mostly use wireless communication, which lacks physical protection in open environments. As long as they are within the coverage area of network transmission, theoretically, anyone can access the network or eavesdrop on the data being transmitted. Therefore, network access authentication and data transmission confidentiality are the two most basic security requirements for IoT perception networks.
Due to the diversity of perception terminals and various access methods, it is challenging to impose uniform requirements on them. Depending on the access target, access authentication can be divided into local perception network access and remote application platform access, one focusing on network layer access and the other leaning towards platform access.
Local perception network access mainly refers to accessing local perception layer gateways, and the access authentication protocols used are usually directly related to the communication methods adopted by the perception network. For example, if the perception network uses WIFI communication, the access authentication protocol typically adopts WPA/WPA2 protocols; if the perception network uses LoRaWAN communication, it generally uses OTAA or ABP protocols. Usually, each mainstream communication method has a corresponding network access authentication protocol.
Remote platform access mainly refers to accessing cloud-based IoT platforms, and the access authentication protocols used must be compatible with the IoT platform. For instance, if the perception terminal supports Alibaba Cloud IoT platform, it needs to support authentication based on MQTT and device key authentication, ID² authentication, or X.509 digital certificate authentication. Many IoT platforms adopt mutual authentication, requiring perception terminals that support platform access to not only support the corresponding access authentication protocols but also generally to have pre-configured keys, authentication certificates, and other information inside the device.
During testing, the access authentication protocol supported by the perception terminal can be checked according to its communication method and access target. A testing environment can then be set up to verify the functionality and security of its access authentication protocol. Below is a brief introduction to testing access authentication for several mainstream communication methods:
1. If the perception terminal (hereinafter referred to as “DUT”) supports WIFI and identity authentication based on WPA/WPA2 security mechanisms, set up a WIFI network and enable WPA/WPA2 access authentication, configure the correct WPA-PSK password or username and password on the DUT, and check whether the DUT can successfully access the network and communicate normally (authentication based on communication protocols/symmetric key);
2. If the DUT supports LoRaWAN communication, set up a LoRaWAN testing environment (including LoRaWAN gateway and LoRaWAN server), manually register the DUT’s DevEUI, activation method (OTAA/ABP), etc., on the LoRaWAN server, configure the corresponding parameters on the DUT according to the registration information, and check whether the DUT can successfully access the network and communicate normally (authentication based on network identity);
3. If the DUT supports Zigbee communication and AES encryption, set up a Zigbee network and enable AES encrypted authentication, set the DUT and Zigbee gateway to use the same pre-shared key or register the DUT key on the Zigbee gateway, and check whether the DUT can successfully access the network and communicate normally (authentication based on symmetric key);
4. If the DUT supports Bluetooth communication, set up a Bluetooth testing environment (including Bluetooth gateway), and check whether the DUT supports connecting to the Bluetooth gateway using a non-just works pairing method and communicates normally; if the DUT supports Bluetooth mesh communication, set up a Bluetooth mesh testing environment (including Bluetooth mesh gateway), and check whether the DUT supports connecting to the Bluetooth mesh network using a non-No OOB (no out-of-band) method and communicates normally (authentication based on symmetric key/asymmetric key);
5. If the DUT supports authentication based on 802.1X, set up a testing environment that supports 802.1X authentication (including 802.1X gateway and Radius server), input the correct username and password on the DUT, and check whether the DUT can successfully access the network and communicate normally (authentication based on network identity/authentication based on communication ports);
6. If the DUT supports identity authentication based on TLS/DTLS protocols, set up a testing environment based on TLS/DTLS protocols (including a server based on TLS/DTLS protocols), and check whether the DUT can access the network and communicate normally via TLS/DTLS; if the DUT supports mutual authentication, try configuring the correct/incorrect certificates on the server to verify whether the DUT can authenticate the server (mutual authentication based on asymmetric cryptography);
7. If the DUT supports access to IoT cloud platforms (such as Alibaba Cloud, Mobile OneNet, or private cloud), configure the DUT to access the cloud platform according to the user manual, and analyze the DUT communication data to verify whether it adopts the claimed identity authentication method (such as Alibaba Cloud certificate authentication);
8. If the DUT supports a mutual identity authentication mechanism based on non-TLS/DTLS protocols, analyze whether this mutual authentication mechanism is secure and set up the corresponding testing environment (including an authentication server) to verify it.
Note: It is important to consider the security of the access authentication protocols themselves. For example, if a WIFI terminal only supports WEP and does not support WPA, its security is evidently insufficient.
In fact, considering the limited computational resources of perception terminals and the diversity of access methods, the standard does not impose mandatory requirements on “supporting access authentication protocols” in the basic requirements but only requires that perception terminals be able to prove their identity to the network. For instance, for perception terminals accessing via wired Ethernet, even if they do not implement any access authentication mechanism, they can still meet the standard requirements in a sense, as their communication data frames carry the terminal’s MAC address, satisfying the requirement for “authentication based on MAC address”. In this case, as long as the gateway supports MAC address-based MAB authentication, a certain level of security can still be achieved (although MAC addresses can be easily forged, and security is not high).
Additionally, some perception terminals, constrained by the lack of input/output devices, cannot configure keys or other information, so access security must rely more on the gateway. As a side note, recently, some smart home products have adopted a clever approach, using Bluetooth instead of traditional serial ports as input/output interfaces. Devices support both Bluetooth and WIFI communication, transmitting WIFI configuration information to the device via Bluetooth, which then connects to the local WIFI gateway based on the configuration information. Bluetooth’s short-range communication provides a certain level of physical security for configuration.
Regarding 5.2.1 c) “Should be able to handle authentication failures”. Handling authentication failures is generally a requirement for gateways (or IoT platforms). When the terminal fails authentication multiple times, the gateway should take protective measures to prevent brute-force attacks on the authentication information. Requiring terminals to have authentication failure handling capabilities is likely targeted at mutual authentication scenarios, where perception terminals access perception networks/platforms, and while proving their identity to the network, they should also check the legitimacy of the accessing network/platform. If it does not match expectations, the perception terminal should take corresponding measures to prevent continuous probing by counterfeit networks/platforms. Since perception terminals typically act as initiators of access authentication, they can simply stop initiating access requests when they detect issues with the accessing network/platform. The “authentication failure handling” here may also be a “system-level” requirement proposed for IoT systems, involving both the gateway/platform and the perception terminal.
Regarding 5.2.1 d) “When using a card-based method for network identity authentication, measures should be taken to prevent the card from being removed or replaced”. Most IoT devices are unattended, and there is a high risk of replacement or impersonation. When counterfeit devices access perception networks/platforms, identity authentication is also required. For identity authentication using a card-based method, if the card on the terminal cannot be removed or replaced, it can effectively reduce the risk of impersonation. On the other hand, for perception terminals using IoT cards for communication, this requirement also helps prevent the theft of IoT cards.
Regarding 5.2.1 e) “Should ensure the security of key storage and exchange”, this is a principle requirement. During testing, both the security of key storage and the security of key exchange can be examined. For key storage, testing can be conducted from two dimensions: first, if the perception terminal’s file system provides external access interfaces, check whether its key information is stored encrypted; second, conduct reverse analysis of the perception terminal’s firmware to check whether key information is stored encrypted. For key exchange, first check for obvious issues such as plaintext transmission of keys, and then analyze the security of its key exchange mechanism through development documents, setting up an environment to verify its functionality and security based on the key exchange protocols employed.
5.2.2 Network Access Control. Among them, 5.2.2 a) “Should disable communication ports that are not required for business” is an application requirement. Each network service port opened by a perception terminal provides an attack target for attackers, so when in use, the attack surface should be minimized by closing all unnecessary service ports. This requirement necessitates that perception terminals have the ability to close non-essential service ports or, by default, only open necessary ports. This requirement may seem simple, but in the industrial sector, it may not always be supported; for example, some mainstream PLC models do not provide the ability to close network services. On the other hand, some IoT terminals are designed not to open any local service ports, connecting to cloud platforms through active connections, which is a good approach.
Regarding 5.2.2 b) “Should set network access control policies to restrict network access to perception terminals”, this appears to be a system-level requirement. Network access control can be implemented by the gateway, by the terminal, or by a combination of both. Given the limited computational resources, perception terminals can implement simple access control through IP whitelisting, etc.
4Communication Security
The standard regulates the use of radio frequencies by perception terminals in section 5.3.1, requiring that the radio frequency bands and radiation intensity used comply with national regulations.
In section 5.3.2, the integrity of communication transmission is regulated, where 5.3.2 a) “Should have and enable a communication integrity verification mechanism to achieve data transmission integrity protection”. During testing, the data transmission integrity verification mechanism (such as message verification code MAC, digital signatures, etc.) can be analyzed based on the perception terminal’s development documentation, and an environment can be set up to verify whether this mechanism can effectively prevent data tampering. If the data verification of the perception terminal only uses a general CRC algorithm without encryption or other security mechanisms, it clearly does not meet the requirements, as attackers can easily attach the correct verification code to tampered data. If a custom verification algorithm is used, it at least has a certain level of security.
5.3.2 b) “Should have mechanisms for handling communication delays and interruptions”, this clause is likely intended to address out-of-order and packet loss during data transmission, with protection mechanisms similar to the sequence numbers and timeout retransmission mechanisms of the TCP protocol. If this assumption is correct, then the perception terminal can satisfy the requirement as long as it uses TCP protocol for data transmission. For those using UDP protocol, corresponding protection mechanisms need to be provided at the application layer.
6.3.3 Data transmission confidentiality “Sensitive information such as authentication information, privacy data, and important business data should be encrypted during transmission”, here confidentiality is treated as an enhanced requirement. As mentioned earlier, many perception terminals use wireless communication, which naturally lacks physical protection. If plaintext transmission is used, it is easy to be eavesdropped. Therefore, confidentiality should be a basic requirement, and most mainstream wireless communications (wifi, zigbee, lora, etc.) also support encrypted transmission. We speculate that confidentiality is treated as an enhanced requirement mainly for wired communication, possibly due to performance considerations. The data encryption and decryption of wireless communication are typically handled by communication chips, which have minimal impact on system performance, whereas encryption and decryption for wired communication are usually implemented by embedded software, which incurs a larger overhead. During testing, it can first be examined whether the communication method adopted by the perception terminal provides encryption mechanisms at the link layer, network layer, transport layer, and application layer; if not, it can be checked whether its application programs take encryption protection when transmitting sensitive information such as authentication information, privacy data, and important business data.
5Device Security
Device security mainly focuses on the security of perception terminals themselves. The standard introduces a concept of “perception terminals with operating systems”. First, let’s explain our understanding of this concept. Most perception terminals are embedded black box devices; some use embedded operating systems, while others are simpler and do not have operating systems. Often, if there is no development documentation, it is difficult to determine whether they have an operating system (some perception terminal operating systems are only meant for multi-tasking and resource management and do not provide external interfaces). In conjunction with the content of the standard, we understand that “perception terminals with operating systems” refers to those that have adopted an operating system and provide user access interfaces for the operating system.
5.4.1 Identification and Authentication, applies only to “perception terminals with operating systems”. It requires that the operating system users of perception terminals have unique identifiers, and user login must involve identity authentication, with user passwords meeting certain complexity requirements. Readers may wonder here; identification and authentication are the most basic security requirements. For those providing management interfaces but lacking operating systems, is there no need for administrator identity authentication? We understand that the standard addresses such cases in 5.4.2 Access Control c) and d) with principle requirements.
6.4.1 Identification and Authentication Enhanced Requirements: “Perception terminals with execution capabilities should be able to authenticate the identity of the instruction issuer”.This requirement for identity authentication is business-level and relates to the specific business protocols (industrial control protocols) used by the perception terminal. It is important to note that the basic requirements mentioned earlier are more management-level, while enhanced requirements are business-level, which are different.
5.4.2 Access Control, where the first two items a) and b) target “perception terminals with operating systems”:“Should be able to control the access rights of operating system users” and “Operating system users should only be granted the minimum permissions necessary to complete tasks”.During testing, different role users (such as operators, auditors) can log into the operating system to check whether the permissions assigned by the operating system to various users are reasonable (e.g., operators should not have the right to delete audit records, auditors should not have the right to perform business operations), while also examining whether the permission assignments comply with the principle of least privilege.
Items c) and d) of 5.4.2 apply to all perception terminals, where 5.4.2 c) “Perception terminals should be able to control local or remote access to data” is a principle requirement. During testing, access control measures such as user authentication, permission control, and IP whitelisting can be examined based on the type of data handled by the perception terminal.
5.4.2 d) “Perception terminals should provide security measures to control their remote configuration”Many perception terminals use private protocols or web methods for remote configuration. During testing, it is necessary to examine whether their configuration methods have security protection mechanisms (such as identity authentication, encrypted authentication, etc.). It should be noted that it is best to separate the management and business aspects of perception terminals, meaning business users can only access business data and not configure the devices, while administrators can only configure and not perform business operations.
6.4.2 Access Control Enhanced Requirement: “Access control scope of the perception terminal system should cover all subjects, objects, and their operations”is a principle requirement. During testing, the existing access control policies of perception terminals can be examined to see if there are any uncovered subjects, objects, and operations between them.
5.4.3 Log Auditing, applies only to “perception terminals with operating systems”, where “Should be able to generate audit records for operating system events, including date, time, operating user, operation type, etc. Should be able to allow security auditors to enable and disable the operating system’s auditing function. Should be able to provide functionality to review the operating system’s audit records”.Since the auditing requirements are essentially the same as those for general devices, they will not be detailed here.
5.4.4 Failure Protection: “Perception terminals should be able to self-detect predefined device failures and issue alerts to ensure that the functions of the unaffected parts of the device remain normal”This clause emphasizes the fault alarm function and availability. During testing, failures such as sensor faults or network faults can be simulated to check whether the perception terminal can issue alerts and whether other functions are affected. For control devices, it is required that communication failures should not affect control functions.
6.4.4 Enhanced Requirement for Failure Protection a) “Perception terminals with operating systems should be able to restart in the event of an operating system crash”This requirement primarily examines whether the perception terminal has hardware designs such as watchdog timers to prevent the operating system from being unavailable for extended periods. Although this requirement is simple, it is difficult to verify since causing the operating system of a perception terminal to crash is not easy. If actual verification is not feasible, examining the perception terminal’s development documentation or hardware design diagrams may be an alternative approach.
6.4.4 Enhanced Requirement b) “Perception terminals with execution capabilities should have local manual control functions, with manual control taking precedence over automatic control functions”This requirement often appears in the industrial sector, such as in power measurement and control devices, where on-site manual control has the highest priority. During testing, corresponding test scenarios can be set up based on the functions and control logic of the perception terminal to verify this functionality.
5.4.5 Software Security, applies only to “perception terminals with operating systems”, where a) “Should only install authorized software”. A more intuitive counterexample would be: for Android devices like RFID data collectors and 4G law enforcement instruments that provide graphical user interfaces, if users are allowed to install apps at will, it poses significant risks. During testing, attempts can be made to install unauthorized general software on the terminal to see if it can be successfully installed.
5.4.5 Software Security b) “Should follow policies for software patch updates and upgrades, ensuring that the updated data is legitimate and complete”During testing, check whether the perception terminal has a software update policy, and by faking data sources, see if it verifies the data source during software updates, and attempt to execute updates using tampered patches or upgrade packages to check if it can succeed.
5.4.5 Software Security c) “Should install software that meets business security function requirements and be correctly configured and used”, 6.4.6 Enhanced Requirement “Software patches for perception terminals with operating systems should undergo security testing and verification before updates and upgrades”, 6.4.7 a) “Should disable idle external device interfaces of perception terminals” and b) “Should disable the auto-start function of external storage devices for perception terminals”All of the above are application requirements for perception terminals. The general principle during testing is that perception terminals should possess the basic capabilities to meet application requirements, such as supporting the disabling of peripheral interfaces and the auto-start function of peripherals.
6Data Security
5.5.1 Data Availability “When transmitting the data collected, perception terminals should indicate the freshness of the data”This clause is mainly aimed at preventing replay attacks, and can be protected by attaching timestamps, sequence numbers, etc., to the data.6.5.1 Enhanced Requirement “Perception terminals should support redundant deployment for collecting important data”During testing, check whether the perception terminal supports redundant deployment according to the user manual, and set up an environment to verify it. There is relatively little information available regarding redundant deployment of perception terminals, but there are specific models of industrial control devices (PLCs) that support redundant deployment (hard redundancy).
5.5.2 Data Integrity “Perception terminals should generate integrity evidence (such as checksums, message digests, digital signatures, etc.) for the data they collect”This clause focuses on the business data collected. During testing, both the integrity of data storage and the integrity of data transmission can be examined, with specific methods referring to sections 5.3.2 and 6.3.3.
6.5.2 Enhanced Requirement “Perception terminals should perform integrity checks on stored authentication information, privacy data, and important business data, and take necessary recovery measures upon detecting integrity errors”During testing, first check whether the file system of the perception terminal provides external access interfaces; if it does, attempt to tamper with authentication information, privacy data, and important business data to see if the perception terminal can promptly detect and take necessary recovery measures.
6.5.3 Data Confidentiality “Perception terminals should use cryptographic algorithms for the storage and transmission encryption protection of sensitive information such as authentication information, privacy data, and important business data. The encryption algorithms should comply with national cryptography regulations”.The standard has already unified the requirements for encrypted transmission of sensitive data in section 6.3.3, while this section mainly focuses on the encrypted storage of sensitive information. The testing methods are similar to those in 5.2.1 e): first, if the file system of the perception terminal provides external access interfaces, check whether its sensitive information is stored encrypted; second, conduct reverse analysis of the perception terminal’s firmware to check whether sensitive data such as authentication information is stored encrypted.
3. Other Testing Considerations
In the testing process of perception terminals, in addition to the content involved in the standards, there are also other matters that need to be noted, such as: checking whether the hardware boards of perception terminals retain debugging interfaces (attackers can use debugging interfaces for information gathering), whether the firmware or core components of the perception terminal have anti-reverse measures, whether the perception terminal (or third-party components used by the perception terminal) has known vulnerabilities, whether there are other ports, services, or special permission pages beyond the manufacturer’s declaration, and whether the implementation of communication protocols is robust enough (communication robustness).
References
1. GB/T 36951-2018 “Information Security Technology – Security Technical Requirements for IoT Perception Terminal Applications”
2. GB/T37024-2018 “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways”
3. “Information Security Technology – Security Technical Requirements for IoT Perception Terminal Applications” Preparation Instructions
4. “IoT Security Standardization White Paper (2019 Edition)”
Original source: Key Infrastructure Security Emergency Response Center
