KR102581174B1 - Whitelisting security method and system for IoT-based multi-framework smart lighting system - Google Patents

Abstract

Provides a whitelist security method and system for IoT-based multi-framework smart lighting system. Communications on the network are protected using Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for TLS/DTLS-compliant devices, or symmetric encryption for TLS/DTLS-compliant devices. A device whitelist is maintained to restrict access by smart lighting system administrators. A client authentication key is used on TLS/DTLS-compliant devices, while a symmetric key is used on TLS/DTLS-non-compliant devices for access control. Additionally, whitelist TLS/DTLS configurations and keys are created based on various capabilities of the device, such as hardware resources, network constraints, and energy consumption. Both policy configuration and TLS authentication keys/hash keys are then distributed only to devices in the whitelist. Therefore, only devices with registered information can create a connection, and the data exchanged on the network is encrypted. Additionally, to enhance security, distributed protocols are designed to periodically update policy sets and keys for all nodes in the network.

Description

Whitelisting security method and system for IoT-based multi-framework smart lighting system {Whitelisting security method and system for IoT-based multi-framework smart lighting system}

System disclosure is generally related to securing an IoT-based multi-frame smart lighting system that deploys lighting in various spaces such as residential, industrial, commercial, and public transportation. Additionally, the system must be operated by an administrator/company with complete management authority over all devices (software/firmware/hardware).

In general, as the Fourth Industrial Revolution and IoT devices develop, the security of IoT networks is very important. IoT-based intelligent lighting systems for smart cities can be applied to various spaces and arrangements. However, IoT-based multi-frameworks security solutions are lacking. Devices in smart lighting systems not only use multiple OS systems such as Windows, Linux, Android, and embedded OS, but also have different resource requirements (hardware capabilities, network constraints, and energy consumption). Communication protocols range from wired, such as LAN and PLC (power line communication), to wireless, such as Wi-Fi, Bluetooth, ZigBee, OpenThread, and LTE. Because smart lighting systems have diverse platforms, it is difficult to apply the same security configuration to all devices in the system. Devices can be divided into categories based on criteria such as hardware capabilities, network constraints, and energy consumption. For example, servers/routers that use power in the network have higher hardware performance compared to battery-equipped IoT devices.

Meanwhile, Transport Layer Security (TLS) is widely used to protect communications in networks. TLS is applied to Transmission Control Protocol (TCP) and Datagram Transport Layer Security (DTLS) to protect User Datagram Protocol (UDP) communications. A cipher suite, which is a set of algorithms, is used in TLS and DTLS. For each TLS version, an appropriate list of cipher suites is generated based on the protocol version by adding secure algorithms and removing those identified as insecure.

Typically, a device comes with a pre-configured list of supported TLS/DLTS versions and ciphers. However, older TLS/DTLS versions and weak cipher suites can still be used. The password list also affects the quality of service of the network and the energy consumption of the device. For example, complex cipher suites can increase the security of a system, but may have higher energy consumption and network overhead.

Smart lighting systems are usually managed by governments or businesses/families, so privacy concerns are high. For example, if you have an app that can connect to a server to access your system, it's not secure. Therefore, access restrictions are necessary to reduce potential attacks. A whitelist of devices that can connect on a system is effective for limiting connection access. First, it should be noted that in a smart lighting system to which the present invention is applied, the administrator can manage and control all devices including hardware, software, and firmware. This allows system administrators to easily maintain a pre-registered device whitelist.

The present invention was proposed to solve the above problems, and the purpose of the present invention is to provide a security solution that can secure communication and access control based on a whitelist maintained by an administrator.

Another purpose of this invention is to provide secure construction of cryptographic algorithms such as TLS/DTLS and cipher suites of symmetric keys.

Another purpose of this invention is to provide a method for periodically distributing security configurations to all devices on a network, for both IP-based and non-IP-based devices.

One aspect of this invention is the use of whitelist-based access control to verify connectivity between devices in a smart lighting system. Administrators have full access to add, modify, or remove devices from the network. The list of registered devices is updated when the administrator operates the system. Therefore, only devices on the registered list can connect to other devices/servers on the network. Devices are managed by administrators, not end users. This is different from a regular IoT network where end users directly purchase devices and integrate them into the system.

Here, security configurations are optimized for each device category in the system, taking into account criteria such as network constraints, hardware performance, and energy consumption. It also uses only sufficiently strong encryption algorithms and eliminates insecure encryption vulnerabilities. In this case, developers should use a Transport Layer Security API or an encryption/decryption API that can support setting the encryption algorithm.

A local server is preferably deployed to provide policy sets or keys to devices on the network. For IP-based devices, this server sends the policy set/key directly to the device's storage path to the IP address extracted from the registered device list. For non-IP based devices, such as smart lighting devices, a hop count based protocol is proposed to distribute security configurations.

According to the smart lighting system using the above invention, only devices registered in a whitelist explicitly permitted by the administrator in advance can access the network. Therefore, it has the advantage of preventing connection risks that may occur from unknown devices. If end users must register themselves, it may be inconvenient for end users. However, in smart lighting, where participating companies develop devices and managers have complete control over the system, device list management is necessary and common.

Additionally, according to this invention, an optimized security configuration can be distributed to each device in the network to achieve balanced performance between processing power, network service quality, energy consumption, and security level of each device. Therefore, in order to choose the optimal security policy, we can conduct some experiments to evaluate the cyber attacks and Quality of Service (QoS) of the network and energy consumption when using that security configuration.

Additionally, according to the invention, the method for redistributing security/configuration keys aims to prevent leakage or decryption of the keys. Additionally, communications protect personal and sensitive information such as passwords and authentication information through TLS/DTLS or appropriate encryption/decryption.

Figure 1 shows an example of a smart lighting system with IoT-based multi-framework devices for four spaces: residential, commercial, industrial, and outdoor.
Figure 2 shows an example of a smart lighting system deployed for a residential space with TLS/DTLS compatible devices in the network.
Figure 3 shows an example of a network topology where IoT-based devices (Zigbee, Bluetooth, WIFI) capable of wireless communication are classified by group ID and device type.
Figure 4 shows an algorithm that aims to determine the group ID of a device in the network as Figure 3.
Figure 5 shows an example network topology where IP-based devices are connected to transmit DTLS/TLS policy sets and TLS client authentication keys.

Figure 1 shows an example of an IoT-based multi-framework lighting system 100 with multiple spaces. Since smart lighting is mainly applied to smart cities, lighting systems (100) are implemented in various spaces and environments such as residential (104), commercial (105), industrial (106), and outdoor (107). Each space has different user and system requirements. The living space (104) can use ZigBee, Wi-Fi, and Bluetooth (108) as main communications. Commercial (105) can use Open Thread and Wi-Fi (109). Meanwhile, Bluetooth and Wi-Fi (110) are used in industry (106). In the case of outdoors (107), where many street lights are placed in a wide area, data is transmitted using power line communication (PLC) and LTE (111). The smart lighting system (100) also includes a Total Operation Center (101) and a cloud service (102) to utilize data collected by smart sensors in the system.

In the case of residential space 104, smart lighting is implemented in houses or apartments. The end user can use the application on the smart remote control 115 or the remote smart light 113 on the user device 116 . The local network is created by the smart gateway/metering gateway 114. The smart gateway/metering gateway 114 uses package transmission/reception and control data/energy consumption data as an intermediate between the smart light 113, smart remote control 115, user device 116, and local server 112. Finally, data collected from the local management server 112 is transmitted to the total operation center 101 or cloud service 102 to support total management/data management/AI/big data applications. Similarly, information collected from 105 Mall, 106 Factory, and 107 Outskirts will be sent to their local management servers. These data will also be transmitted to comprehensive center 101 and cloud service 102 for more effective useful work.

In a smart lighting system with many devices, it is important to restrict access to devices not managed by the administrator for security purposes. Therefore, not all devices can connect to the server without permission. The management server maintains a whitelist of devices based on device information (e.g. device ID, MAC address).

Assume that your network contains devices that support TLS/DTLS (TLS/DTLS-compatible devices) and other devices that do not support TLS/DTLS (TLS/DTLS-incompatible devices). Authentication keys are refreshed and redistributed periodically (e.g. every two weeks) to prevent authentication attacks that could use shared credentials to access many devices on the network. For devices that are not DTLS/TLS compatible, each device must use a "key" for authentication. Security keys are used for authentication between devices (e.g., client and server) because non-TLS devices do not have sufficient computational power to use complex encryption algorithms.

TLS is used for TCP communication and DTLS is used for UDP communication, and in commercial products, the server supports all TLS communication (i.e. TLS v1.0, TLS v1.1, TLS v1.1, TLS v1.3) (TLS v1.0 and v1.1 are not supported in smart lighting systems) . It is recommended not to support lower versions of TLS due to vulnerabilities. Currently, at the time of invention registration, the latest version of TLS is 1.3, and the version of DTLS is 1.2 (DTLS version 1.3 is under development).

It is assumed that the software/firmware of the smart lighting system can be completely controlled. Whitelist-based policy configuration for Transport Layer Security is TLS/DTLS and TLS/DTLS cipher suites. The present invention currently only supports TLS v1.2 and TLS v1.3, and supports the highest version with strong security.

Additionally, only the set of supported cipher suites is selected for each TLS version, and the choice of cipher suites also depends on the performance of the device. For example, for high-performance devices such as management servers, it is recommended to use complex/high security cipher suites. Simple IoT devices with TLS/DTLS implemented only use low-complexity cipher sets.

For example, for TLS v1.3, only the two cipher suites {TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384} below are supported. For TLS v1.2 {TLS_DHE_RSA_WITH_AES_128_GCM_SHA256; TLS_ECDHE_RSA_WITH_128_GCM_SHA256; TLS_DHE_RSA_WITH_S256; TLS_RSA_RSA256 is supported.

TLS policies, such as TLS version and TLS cipher suite set, are distributed to all devices on the network through a periodic distribution protocol described in the next chapter.

Figure 2 shows an example of a smart lighting system 200 with DTLS/TLS compatible devices. As you can see, due to the variety of devices, it is not possible to apply all the latest DTLS/TLS versions. Therefore, considering hardware resources, network constraints, and energy consumption, supportable DTLS/TLS versions and cipher groups are defined based on device information and testing.

For example, Smart Lighting 1 (SL1) 201 includes LED 206 and Smart Sensor 207. SL1 201 protects data with SL2 202 and SL5 205 by DTLS version 1. In SL2 202, smart meter gateway 209 uses TLSv1.2 and DTLS v1.2 to exchange data, while smart lighting gateway 208 uses TLSv1.3 and DTLSv1.2 for security. Likewise, the broker 210 of SL3 203 and the lighting management server 211 of SL4 204 also support both TLSv1.2 and TLS v1.3. Additionally, TLSv1.2 used in the smart metering gateway 209 and the wall pad 213 is applied to two platforms: the Android OS of the wall pad 213 and the embedded OS of the smart meter gateway 209.

Therefore, the supported TLS versions may not be consistent due to multiple frameworks. Project managers must consider and select appropriate TLS/DTLS versions and cipher suites.

Figure 3 shows an example of a network structure used to transmit data (TLS keys/hash keys) to IoT devices that do not use IP addresses for routing. This protocol applies only to wireless IoT networks (Zigbee, Thread, Wi-Fi, BLE mesh).

The protocol includes two steps:

Step 1: The server collects network topology information.

Step 2: Policy sets and/or keys are distributed to clients on the network. Only devices on the whitelist will have policy configuration and keys sent.

In step 1, network topology information includes device ID, group ID, and the node's neighboring devices. The device ID is the product's unique number. The group ID is the sink's multi-hop count, from which the network deployment can be drawn in detail.

As shown in Figure 3, network topology 300 includes policy set/key distribution server 301 and seven nodes. A whitelist of devices 309 is maintained on server 301. The group ID of server 301 is 0. The node in group 1 is a node with 1 hop count of server 301. Nodes E302, B303, A304 and node C305 are in group 1. The group ID of nodes B 306, A 307, and D 308 is 2. Each node has a unique device ID, node D308 has a device ID equal to 7. The algorithm for assigning a node's group ID is shown in Figure 4.

In step 2, policy sets and/or security keys are distributed to all nodes registered in a whitelist maintained on the policy/key distribution server. For example, a policy set includes the following information:

No. Fields Value One TLS protocol 0: no support1: TLS
10: DTLS 2 TLS version 0: 1.21: 1.3 3 Cipher number 1-100 4 Cipher list E.g., c0 0a - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

For TLS/DTLS-compatible devices, client authentication uses the client authentication's public key to decrypt data (this procedure is handled by the TLS handshake protocol). Client keys are created according to the TLS standard.

Figure 4 shows a flowchart of an algorithm for determining the group ID of a node in an IoT device. Initially, the group ID (sink) of the distribution server is assigned to 0. The group ID initialization of other groups is set to infinite. At this stage, all nodes are active and not in sleep mode, and sinks and other devices broadcast greeting messages with their group IDs. When a node receives a Hello message, it compares the received group ID with the current group ID. Assume that node A with group ID i (i > 0) receives the hello message from note B with group ID j. Then the group ID of node A is calculated as follows:

Figure 5 shows an example network topology 500 of an IP-based device. Because it is an IP-based device, deployments can send security policies and keys directly based on IP addresses. These devices then store the configuration and keys for use in future communications. For example, Policy/Key Distribution Server 503 allows administrators to maintain a list of IP addresses of all devices. So when client 501, 502, 504 or 505 sends a request, server 503 distributes the policy/key to them and packets can be sent over TCP/UDP.

101: Total Operation Center (TOC)
102: Cloud Services
112: Local Management Server
104: Living space
105: Commercial space
106: Industrial space
107: Outdoor space
113: Smart Lighting (Intelligent Lighting Device)
114: Smart Gateway/Metering Gateway
115: Smart Remote
116: User Device
207: Smart Sensor
210: Broker (MQTT Brocker)
212: Smart Controller
213: Wall-pad: Android table attached to the wall
214: Mobile application

Claims (6)

In a security method for an IoT-based multi-framework smart lighting system configured through a network including devices that support Datagram Transport Layer Security (DTLS)/Transport Layer Security (TLS) and devices that do not support DTLS/TLS,
A server provided in the IoT-based multi-framework smart lighting system collects topology information of the network;
the server periodically transmitting a security policy and key to devices registered in a predetermined whitelist among clients that are devices that do not use an IP address included in the network according to the topology information at predetermined times;
The server transmitting a security policy and key based on the IP address to devices registered in a predetermined whitelist among clients that regularly use the IP address included in the network at a predetermined period of time; and
Devices that have received the security policy and key store the security policy and key,
Clients and servers in the network communicate by authenticating using the security policy and key,
The topology information includes device ID and group ID,
The device ID is a unique ID for the device,
A security method characterized in that the group ID is determined according to Equation 1 by receiving hello messages broadcast by devices belonging to the network to set the group ID.
Equation 1

In Equation 1, i is the current group ID for each device in the network, j is its group ID sent by each device in the network in a hello message to determine the group ID, and i is initialized to 0 and j is initialized to infinity. delete According to paragraph 1,
The security policy includes information about the TLS protocol and version;
The information about the TLS protocol includes identification information for any one of no support, TLS, and DTLS,
The version information includes information about the version of TLS or DTLS,
When the server communicates with each device included in the network, if the information on the TLS protocol is identification information indicating that it does not support the TLS protocol, the server performs authentication between the client and the server using a security key and communicates;
If the information about the TLS protocol is identification information about the TLS or DTLS, and the information about the version includes information about the version of TLS or DTLS, communication is performed according to the TLS or DTLS method according to the TLS or DTLS version. A security method characterized by
delete delete delete