Exploring Vulnerabilities in Smart Cities and Developing Simulation Environments - 1

In October 2023, the Ministry of Science and ICT and IITP (Institute of Information & Communications Technology Planning & Evaluation) hosted a Cyber Security Challenge in South Korea. ZIEN participated in this competition, focusing on analyzing vulnerabilities in smart cities and effectively addressing them, ultimately achieving 4th place overall.

The simulated smart city environment provided visual interest throughout the competition. The dynamic response of traffic lights and streetlights to simulated attacks was intuitive and engaging, even for those not well-versed in security concepts.

This article aims to delve into the protocols and architecture of smart cities, particularly those explored and researched while creating the simulated environment used in the competition.

☑️ Essential Information Before Creating a Smart City

Before diving into the development of a smart city, it's important to grasp the prevalent protocols, their applications, and the equipment involved.

In the realm of smart cities, Operational Technology (OT) equipment plays a significant role, relying on protocols like OPC UA and MQTT. Similarly, BACnet stands out as a commonly used protocol in smart building environments.

Equipment commonly found in the OT sector includes Programmable Logic Controllers (PLCs), responsible for managing electrical signals, and Human-Machine Interfaces (HMIs), which offer users visual feedback based on memory states and enable straightforward operation.

Smart City Protocol

OPC UA

OPC UA is a standard protocol for facilitating data communication and information exchange within industrial automation and control systems. The landscape of industrial equipment spans decades, with numerous companies worldwide manufacturing their own devices. This diversity has led to the adoption of various protocols across different industrial systems.

Integrating these disparate protocols is a significant challenge. To address this issue, equipment manufacturers have developed products that support the OPC UA protocol, thereby enhancing compatibility among different equipment within industrial setups. OPC UA operates by establishing sessions between clients and servers via TCP/IP or specific communication protocols. Clients can then interact with server tags, enabling seamless communication among interconnected devices.

This protocol has been instrumental in standardizing communication across industrial equipment, making it easier to support diverse platforms and operating systems. Furthermore, OPC UA prioritizes security by granting access only to authenticated users, thus ensuring the safe transmission of industrial data.

Despite its advantages, OPC UA does have its limitations. Its requirement for continuous real-time communication with servers can lead to high resource consumption, making it less suitable for use in smaller embedded systems. Additionally, the abundance of features coupled with limited explanatory resources creates a steep learning curve for new users.

MQTT

(Message Queuing Telemetry Transport)

MQTT is a lightweight Publish-Subscribe messaging protocol used for efficient data exchange among various devices and applications.

In various industries, a multitude of devices and systems employ diverse communication protocols for data transmission, resulting in integration complexities and limited interoperability. MQTT was developed as a solution to these challenges. It utilizes a Publish-Subscribe model for message exchange among clients, allowing them to subscribe to specific topics and publish messages to those topics.

To facilitate communication, clients connect to an MQTT broker. This broker efficiently manages message routing between clients, delivering published messages to all subscribers of the corresponding topics.

MQTT's lightweight and straightforward design enables efficient operation in embedded systems and various network environments. Furthermore, it conserves network bandwidth by allowing message exchange without the need for persistent connections. However, MQTT lacks inherent mechanisms for ensuring message reliability. Consequently, some applications may require additional security and error-handling features to guarantee message delivery.

BACnet

(Building Automation and Control Networks)

BACnet stands as the gold standard protocol for orchestrating building automation and control networks, designed to streamline communication among a diverse array of facilities and devices within a structure. It functions as the digital maestro behind the scenes, harmonizing heating, cooling, lighting, access control, and surveillance systems for optimal building management.

At its core, BACnet is engineered to foster seamless communication among a wide range of devices and systems. By leveraging a standardized data model, it empowers buildings to represent their myriad facilities and devices cohesively, facilitating fluid data exchange.

This versatile protocol supports communication among devices within a building by accommodating various network and physical communication media. It enables interaction through multiple communication protocols, including Ethernet, RS-485, and BACnet/IP.

Moreover, BACnet defines an extensive set of services and objects to support the diverse requirements of building automation systems. These services and objects are capable of performing various functions such as data reading, writing, and event notifications.

However, it's crucial to note that improper design of BACnet systems can lead to challenges in modification and verification. Additionally, security issues may arise when data from various protocols is consolidated into a single protocol. Therefore, appropriate design and management are essential for the effective utilization of BACnet.

OT Devices

Gateway

WEINTEK CMT-G01

A gateway serves as a bridge, facilitating communication and conversion between two or more distinct networks or protocols. Its primary function is to manage protocol and data format conversions among connected networks, ensuring seamless compatibility. This interconnectivity enables devices using different communication protocols to interact, thereby fostering integration across diverse systems.

In our current simulation environment, we've established connectivity between HMI and PLC. For this purpose, we've selected WEINTEK's CMT-G01, a versatile device that supports an OPC UA server and provides robust MQTT communication capabilities.

PLC

LS ELECTRIC XBC-DR30E

PLCs (Programmable Logic Controllers) are digital control devices widely employed in industrial automation and control systems, particularly in manufacturing processes and machinery automation. These devices integrate programmable logic and control functions with input/output capabilities to execute a variety of control and automation tasks.

PLCs run user-defined programs to detect input signals and control outputs accordingly, functioning as the core component in process management. For our simulation environment, we've chosen LS Electric's XBC-DR30E model, which supports RS232 and RS485 communication protocols. To develop ladder logic for this PLC, we'll utilize LS Electric's XG5000 programming software.

HMI

WEINTEK MT8072iE

HMI (Human Machine Interface) refers to a device that provides an interface for interaction between users and equipment, facilitating the monitoring and operation of control systems. Typically featuring touchscreens, HMIs offer intuitive visual displays of information and enable user interaction.

In manufacturing environments, HMIs provide a range of functionalities, including process monitoring, control system configuration and operation, and visualization of production data. Working in tandem with Programmable Logic Controllers (PLCs), HMIs display data collected by PLCs to users and relay user inputs back to the PLCs for control and operational purposes.

To ensure seamless integration with gateways, we've selected the MT8072iE model from the same manufacturer, renowned for its MQTT support.

☑️ Simulated Environment Development

After researching the protocols and equipment required for creating a simulated environment, we have drafted a diagram outlining the configuration of a smart city based on the system of the competition.

Smart City Layout

Development of Smart City Components

Streetlights

Streetlight control is achieved through the manipulation of PLC outputs using the OPC UA protocol provided by the gateway.

To accomplish this, a P200 tag in OPC UA is utilized to configure a BOOL[100] variable, with BOOL[34] designated as the data responsible for controlling the streetlights.

As the PLC processes BOOL data at the BIT level upon transmission, the value at index 34 (the 35th value), based on HMI address DW_Bit 3000 (D0300.0 on the PLC), translates to D0302.2, enabling streetlight control. This method allows for effective manipulation of streetlight power.

Process

1. Integrate PLC into the gateway system.

2. Activate the RS232 port on the PLC (Ensure matching baud rate and station number)

3. Configure a BOOL tag in OPC UA on the gateway for controlling streetlight power

4. PLC addresses vary based on the alphabet, with the D area typically used for data
(P area for input/output, and BIT with .0 appended at the end)

5. In the PLC logic, manipulate streetlight power based on received data (e.g. D0302.2)

Traffic Lights

The timing mechanism for traffic signals is designed similarly to streetlights and is configured for manipulation through the OPC UA protocol. However, relying solely on OPC UA for real-time data display on the HMI may present limitations.

To address this, while the timing mechanism of traffic signals remains configurable via OPC UA, real-time data representation on the HMI is facilitated through an MQTT Broker. This dual-protocol approach ensures that the HMI can accurately portray the real-time status and remaining duration of traffic signals based on data streamed through the MQTT protocol.

Process

1. Install the Mosquitto MQTT server and configure the MQTT version for connection

2. Set up a TOPIC and specify the data type with the same QoS as the MQTT server

3. Define the type and address of the data to be used in the designated TOPIC. Since it transitions to JSON format, multiple types can be utilized

# Format of the data being sent
{
	"d": {
		"name": [value at address]
	}
}

4. Choose an HMI from the ie series supporting MQTT, ensuring MQTT activation

5. Similar to the configuration on the Gateway, the HMI for traffic signals merely needs to read data from MQTT. Subscribe to the MQTT topic and designate the address to store the read data

PLC Ladder Logic

Drone Parking Management System

For our project, we leveraged open-source image-based parking space occupancy classification.

🔗Source Code from : https://github.com/martin-marek/parking-space-occupancy

🔗Artificial Intelligence Model Source : https://github.com/martin-marek/parking-space-occupancy

1. Mark coordinates to define parking spaces in the sequence provided below.

   

2. Utilize open-source software and models to recognize parking spaces and determine occupancy status.

   

We developed a drone parking management system tailored for smart cities using open-source software and publicly available artificial intelligence models.

Building Management System

Equipment supporting BACnet is primarily utilized by construction companies, and there's no direct way for the general users to acquire such equipment. Therefore, we've employed Raspberry Pi to establish a BACnet server.

For this purpose, we employed the BAC0 BACnet server available in Python and developed an API server using Flask to manage the system's operations comprehensively.

LED On 1, Off 0

LED On / LED Off

Smart City Surveillance Camera

Due to challenges in vendor selection stemming from the need to disclose camera vulnerabilities, we opted to create our own surveillance system using Raspberry Pi devices with custom-designed web vulnerabilities.

To achieve real-time web streaming of the Raspberry Pi camera feed, we employed ffserver to capture live video data and ffmpeg to convert and transmit this data to a web server.

Initially, the ffserver setup process presented several challenges, resulting in suboptimal video output. However, we successfully achieved web streaming by converting the video to the mjpeg format.

We deployed lighttpd as the web server and implemented CGI functionality directly in C language. This approach enabled us to incorporate features such as NTP server setup, DHCP configuration, static IP address assignment, and camera on/off controls. Subsequently, we configured ffserver and ffmpeg as services, enabling the Raspberry Pi to transmit video data continuously, thus completing the implementation of the camera functionality.

☑️ The Finalized Simulated Environment