WO2023080278A1

WO2023080278A1 - Whitelisting security method and system for iot-based multi-framework smart lighting system

Info

Publication number: WO2023080278A1
Application number: PCT/KR2021/015956
Authority: WO
Inventors: Son VU DUY
Original assignee: Realsecu Co., Ltd.
Priority date: 2021-11-04
Filing date: 2021-11-04
Publication date: 2023-05-11

Abstract

A whitelisting security method and system for IoT-based multi frameworks smart lighting system is provided. A whitelist of devices is maintained to limit access by the administrator of the system. For access control, a client authentication key is used for transport layer security (TLS) / datagram transport layer security (DTLS) compatible devices where a symmetric key is used for TLS/DTLS non-compatible devices. In addition, a whitelisting TLS/DTLS configuration and key are built based on the diversity of devices' capabilities such as hardware resources, network constraints, and energy consumption. Then both policy configuration and TLS authentication key/hash key are only distributed to devices in the whitelist. Therefore, only the device whose information is registered can create connections, and the exchanged data in the network are encrypted. Furthermore, to be more secure, a distributed protocol is designed to periodically renew policy sets and keys to all nodes in the network.

Description

WHITELISTING SECURITY METHOD AND SYSTEM FOR IOT-BASED MULTI-FRAMEWORK SMART LIGHTING SYSTEM

The system disclosure relates generally to securing an IoT-based multi-framework smart lighting system in which the lights are deployed in a variety of spaces such as residences, supermarkets, and public traffic. Furthermore, the system needs to be operated by administrators/companies who totally managed all devices (software/firmware/hardware).

With the development of industry 4.0 and IoT devices, the security of IoT networks is very important. An IoT-based intelligent lighting system for a smart city can be applying to a plurality of space and deployment layouts. However, there is a lack of security solutions for IoT-based multi frameworks. The devices in the smart lighting system not only use several OS systems, e.g., Windows, Linux, Android, embedded OS but also have different resource requirements (e.g., hardware capability, network constraints, and energy consumption). The communication protocol is also various, from wired such as LAN, Power Line Communication (PLC) to wireless such as WIFI, Bluetooth, Zigbee, Open thread, or LTE. Because of the diversity of platforms in the smart lighting system, it is hard to apply the same security configuration to all devices in the system. The device may be divided into categories according to criteria such as hardware ability, network constraint, and energy consumption. For example, the server/router using electric power in the network usually has high hardware performance compared to IoT devices which may be equipped with a battery.

Transport Layer Security (TLS) is widely used for securing communication in the network. While TLS is applied for Transmission Control Protocol (TCP), a Datagram Transport Layer Security (DTLS) based on TLS is developed to secure User Datagram Protocol (UDP) communication. A cipher suite, a set of algorithms, is used in TLS and DTLS. For each version of TLS, an appropriate cipher suites list is built based on the protocol version by adding secure algorithms and removing algorithms that are identified as insecure. 　　

Usually, the supported TLS/DLTS version and cipher suite used in a device is preconfigured. However, the old TLS/DTLS version and vulnerable cipher suites can be still used. Furthermore, the cipher suites affect the quality of service (QoS) in the network and the energy consumption of devices. For example, a complex cipher suite can make a system more secure, but the energy consumption and network overhead can be higher.

Because the smart lighting system is usually managed by the government or a company/family, privacy is highly concerned. For example, it is insecure if any app can connect to a server to access the system. Thus, access limitation is required to reduce potential attacks. A whitelist of devices allowed to make the connection in the system is efficient to limit the connection access. It should be noted that in the smart lighting system wherein the present invention is applied, the administrator can manage and control all devices including hardware, software, and/or firmware. Therefore, a pre-registered device whitelist can be easily maintained by the administrator of the system.

The present invention was proposed to solve the above-mentioned problem, and an object of this invention is to provide a security solution to secure communication and access control based on a whitelist maintained by the administrator.

Another purpose of this invention is to provide a security configuration of cryptography algorithms such as cipher suites in TLS/DTLS and symmetric keys.

Another purpose of this invention is to provide a method to periodically distribute security configuration to all devices in the network, for both IP-based and non-IP-based devices.

One aspect of this invention is using the whitelist-based access control to verify the connection between devices in the smart lighting system. The administrator has full permission to add, modify or remove devices in the network. The registered device list is updated when the administrator operates the system. Therefore, only devices in the registered list can make the connection to the server/ another device in the network. Note that the device is managed by the administrator, not the end-user. This is different from a general IoT network where the end-user buys and integrates the device into the system themselves.

Here, the security configuration is optimized for each category of device in the system, by considering criteria, i.e., network constraint, hardware performance, and energy consumption. In addition, only the cryptography algorithms which are strong enough are used and the insecure cryptography vulnerable are removed. In this case, the developer needs to use a transport layer security API or encryption/decryption API which can support setting cryptography algorithms.

Preferably, the local server is built to deliver policy sets or keys to devices in the network. For IP-based devices, this server directly transmits the policy set/key to a save path in the device by IP address which is also 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 configuration.

According to the smart lighting system using this invention described above, only the registered device in the whitelist which is explicitly allowed in advance by the administrator can make a connection in the network. Thus, it has the advantage of preventing potential risks of connection from unknown devices. In case end-users have to register themselves, it can be inconvenient for end-users. However, in the smart lighting in which the devices are developed by companies joined in the project and the administrator can fully control the system, the managing device list is necessary and common.

Also, according to this invention, the optimized security configuration is distributed to each device in the network, this leads to achieving a balance performance between processing ability, network quality of service, energy consumption, and security level of each device. Therefore, to select a desired optimized security policy, some experiments can be progressed to evaluate the safety under cyber-attacks and the QoS (Quality of Service) of network and energy consumption when using that security configuration.

Also, according to this invention, the method for redistributing security/configuration keys aims to prevent the key from leaking or decrypting. Furthermore, the communication is also secured by TLS/DTLS or appropriate encryption/decryption to protect exchanged data, private and sensitive information such as passwords, credentials.

FIG. 1 illustrates an example of a smart lighting system having IoT-based multi frameworks devices with 4 spaces: residence, mall, factory, and outdoor;

FIG. 2 illustrates an example of a smart lighting system deployed for residence space with TLS/DTLS compatible devices in the network;

FIG. 3 illustrates an example of a network topology in which IoT-based devices with wireless communication (Zigbee, Bluetooth, WIFI) are classified by group id and device type;

FIG. 4 illustrates an algorithm that aims for determining the group ID of the devices in the network as FIG. 3; and

FIG. 5 illustrates an example of a network topology in which IP-based devices are connected to transfer DTLS/TLS policy set and TLS client authentication key.

FIG. 1 illustrates an example of an IoT-based multi frameworks lighting system 100 with several spaces. Since smart lighting is usually applied to smart cities, the lighting system 100 is implemented in a variety of spaces and environments such as residence 104, mall 105, factory 106, and outdoor 107. Each space has different user and system requirements. The residence space 104 may use ZigBee, WIFI, and Bluetooth 108 as main communications. Mall 105 may use OpenThread and WIFI 109. Meanwhile, Bluetooth and WIFI 110 are used in factory 106. For outdoor 107 where many street lights are deployed in a wide area, the Power Line Communication (PLC) and LTE 111 are used to transfer data. The smart lighting system 100 also includes total operation center 101 for total management and cloud services 102 to exploit the data collected by smart sensors in the system.

For residence space 104, smart lighting is implemented in a house or apartment. End-users can use smart remote 115 or an application in user's device 116 to remote smart light 113. A local network is created by a smart gateway/metering gateway 114. The smart gateway/metering gateway 114 is used as an intermediate to transmit/receive the package and sent control data/energy consumption data between smart light 113, smart remote 115, user 'device 116, and local server 112. Finally, the collected data in the local management server 112 is sent to the total operation center 101 or cloud services 102 to supports total management/ data management/ AI/Big data applications. Similarly, the information collected in mall 105, factory 106, and outdoor space 107 will be sent to their local management server. These data are also to be transmitted to total operation center 101 and cloud services 102 for more effective useful tasks.

In smart lighting system where there are a lot of devices, for security, it is important to limit access of device which is not managed by an administrator. Thus, not every device can make a connection to the server without permission. The management server maintains a whitelist of devices based on device information (e.g., device ID, MAC address).

Supposed that the network includes devices that support TLS/DTLS (TLS/DTLS compatible device) and the other, which does not support TLS/DTLS (TLS/DTLS incompatible device). To prevent authentication attacks that can use sharing credentials to access many devices on the network, the authentication key is renewed and re-distributed periodically, e.g., 2 weeks. For DTLS/TLS incompatible devices, each device has to use a “”to make authentication. Because that non-TLS device does not have enough computation power to use a complicated cryptography algorithm, a security key is used to make authentication between devices (e.g., client and server).

TLS is used for TCP communication, while DTLS is used for UDP communication. In commercial products, their server supports all TLS versions. Because of the vulnerability, it is recommended that do not support the older version of TLS. At the time of registering the present invention, the latest version of TLS is 1.3, and the DTLS version is 1.2 (DTLS version 1.3 is under development). In commercial products, their server supports all TLS communication (i.e., TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3). Because of the vulnerability, it is recommended that do not support the older version of TLS. For example, TLS v1.0 and v1.1 are not supported in the smart lighting system.

Supposed that these considering smart lighting system can is implemented in full control of software/firmware. The whitelist-based policy of transport layer security is the configuration of supportable TLS/DTLS version, and TLS/DTLS cipher suites. And only TLS v1.2 and TLS v1.3 are supported.

For each TLS version, only a set of cipher suites is selected. The selection of cipher suite is also depending on the computation capability and time of the device. For example, for a device that has high performance like a management server, it is recommended to use a complicated/high-security cipher suite. While for simple IoT devices which are implemented TLS/DTLS, only a low complicated cipher suite set is used.

For example, for TLS v1.3, only two below cipher suite is supported: {TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384}. For TLS v1.2, 4 cipher suites will be supported: {TLS_DHE_RSA_WITH_AES_128_GCM_SHA256; TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; TLS_DHE_RSA_WITH_AES_256_GCM_SHA384; TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384}.

The TLS policy such as TLS version, TLS cipher suite set will be distributed to all devices in the network by a periodically distributed protocol which will be presented in the next chapter.

FIG. 2 illustrates an example of a smart lighting system 200 with DTLS/TLS compatible devices. As can be seen, because of the variety of devices, the latest DTLS/TLS version cannot be applied to all. Thus, by considering the hardware resource, network constraint, and energy consumption, the supportable DTLS/TLS version and cipher suites are defined by on the information of the device and after testing.

For example, smart lighting 1 (SL1) 201 contains LED 206 and smart sensor 207. SL1 201 secured data with SL2 202 and SL5 205 by DTLS version 1. In SL2 202, while smart meter gateway 209 exchanges data using TLSv1.2 and DTLS v1.2, smart lighting gateway 208 use TLSv1.3 and DTLSv1.2 for securing. Similarly, broker 210 in SL3 203 and lighting management server 211 in SL4 204 supports both TLSv1.2 and TLS v1.3. In addition, TLSv1.2 used in smart metering gateway 209 and wall pad 213 are applied to two different platforms, e.g., Android OS in wall-pad 213 and embedded OS in smart meter gateway 209. Thus, the supported TLS version of devices cannot be consistent because of the multi frameworks. The project manager should consider and select appropriate TLS/DTLS versions and cipher suites that are suitable.

FIG. 3 illustrates an example of a network topology that is used to transfer data (TLS key/hash key) to IoT devices that are not used IP addresses for routing. Thus, this protocol is only applied to wireless IoT networks (Zigbee, Thread, WIFI, BLE mesh).

The protocol includes two phases:

Phase 1: The server collects the network topology information.

Phase 2: A policy set and/or key is distributed to the client in the network. The only device in the whitelist is sent the policy configuration and key.

In phase 1, the network topology information includes device ID, group ID, and node's neighbor. The device ID is a unique number of a product. The group ID is the number of multi-hop counts from the sink. From that, a network topology can be drawn in detail.

As can be seen in FIG.3, the network topology 300 includes a policy set/key distribution server 301 and seven nodes. A whitelist of devices 309 is maintained at server 301. The group ID of server 301 is zero. Nodes in group 1 are nodes that have a 1-hop count from server 301. Nodes E 302, B 303, A 304, and node C 305 are in group 1. Node B 306, A 307, D 308 has group ID which equals 2. Each node has a unique device ID, node D 308 has a device ID that is equal to 7. The algorithm to assign the group ID of nodes is shown in FIG.4.

In phase 2, a policy set and/or security key is distributed to all nodes which are registered in the whitelist maintained in the policy/key distribution server. For example, a policy set includes below information:

No.	Fields	Value
1	TLS protocol	0: no support1: TLS 10: DTLS
2	TLS version	0: 1.2 1: 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, the client authentication is used, in which the public key in the client certificate is used to decrypt data (this procedure is processing in handshake protocol of TLS). The client key is made under the TLS standard.

FIG. 4 illustrates the flow chart of an algorithm to determine the group ID of nodes in IoT devices. In the beginning, the Group ID of the distribution server (the sink) is assigned to zero. The initialize group ID of the others is set to infinity. In this phase, all nodes are active and do not sleep. Then the sink and other devices broadcast hello messages with their group ID. When a node receives a hello message, it will compare the received group ID and the current group ID. Suppose that a node A whose group ID equals i (i>0) receives a hello message of note B whose group ID equals j. Then the group ID of node A (

) is calculated as follows:

FIG. 5 illustrates an example of a network topology 500 for IP-based devices. Since it is an IP-based device, the distribution can send directly security policy and keys based on IP address. Then these devices will save the configuration and key to use in future communication. For example, a policy/key distribution server 503 maintains a list of IP addresses of all devices by the administrator. Thus, when a

client

501, 502, 504, or 505 sends a request, the server 503 will distribute the policy/key to them. The packets can be sent under TCP/UDP.

Claims

A whitelisting security method for IoT-based multi-framework smart lighting system, the method comprising:

Determining a whitelist of cryptography policy configuration that is applied for transport layer security (TLS) and symmetric encryption algorithm; and

Designing a distribution method to deliver policy configuration and authentication keys to devices that are maintained in a whitelist of devices by the administrator of the system.
The IoT-based multi-framework smart lighting system of claim 1 comprising:

several spaces for deploying smart lighting system such as residence, mall, factory, and outdoor; and

a plurality of IoT devices and servers, smart gateway, metering gateway with multi-framework, different hardware specification, and network constraints; and

the administrators who manage and maintain the system, i.e., the device integrated into the system need to be permitted by the administrator.
The devices in the smart lighting system in claim 2 wherein the devices are classified into two categories:

the TLS/DTLS incompatible devices that cannot apply TLS because of limitation of hardware resources and supported framework; and

the TLS/DTLS compatible devices that can support TLS/DTLS whose version and cipher suites list can be variant depends on the supported framework.
The whitelist of cryptography policy configuration of claim 1 comprising:

a TLS/DTLS version and cipher suites list for TLS/DTLS compatible devices; and

symmetric encryption algorithm for TLS/DTLS incompatible devices.
The method for building up the whitelist of the cryptography policy configuration in claim 4:

optimizing system performance by considering hardware resources, network constraints, and energy consumption; and

testing and selecting appropriate security parameters by experiment in a testbed.
The whitelist of managed devices in claim 1 comprising:

the specific information of devices such as device ID, device category, MAC address, etc. which are used to make the TLS authentication key/symmetric key for connection verification, e.g., only device in the whitelist can connect to the server.
The distribution method of cryptography configuration and authentication key in claim 1, wherein the local policy/key distribution server delivery policy/key to both IP-based devices and non-IP-based devices.

For IP-based devices, the configuration files are distributed to the device by IP address and pre-determined path in the client; and

For non-IP-based devices, the policy/key distribution server implements a protocol to determine the group ID of devices based on hop-counts, then building a group-based hop-count routing protocol to deliver configuration files to clients.