Smart parking systems are a crucial component of the “smart city” concept, especially in the age of the Internet of Things (IoT). They aim to take the stress out of finding a vacant parking spot in city centers, due to the increasing number of cars, especially during peak hours. To realize the concept of smart parking, IoT-enabling technologies must be utilized, as the traditional way of developing smart parking solutions entails a lack of scalability, compatibility with IoT-constrained devices, security, and privacy awareness. In this paper, we propose a secure and privacy-preserving framework for smart parking systems. The framework relies on the publish/subscribe communication model for exchanging a huge volume of data with a large number of clients. On one hand, it provides functional services, including parking vacancy detection, real-time information for drivers about parking availability, driver guidance, and parking reservation. On the other hand, it provides security approaches on both the network and application layers. In addition, it supports mutual authentication mechanisms between entities to ensure device/ data authenticity, and provide security protection for users. That makes our proposed framework resilient to various types of security attacks, such as replay, phishing, and man-in-the-middle attacks. Finally, we analyze the performance of our framework, which is suitable for IoT devices, in terms of computation and network overhead.
Due to the rapid increase in automobile numbers, finding an available parking space in city centers during peak hours has become a serious problem for drivers. It is estimated that 30% of daily traffic jams in crowded areas is caused by car-owners looking for vacant parking spaces, and that a driver spends, on average, 7.8 minutes trying to find an available spot [
To minimize hassle and inconvenience for drivers, several solutions have been proposed in recent years. Most of them entail building parking guidance information (PGI) systems for better parking management [
To solve the aforementioned parking problems, and to fully realize the concept of a smart parking system, IoT-enabling technologies must be taken into account. This paper proposes a secure and privacy-preserving framework for smart parking systems called SecSPS, which consists of three main components: a sensor network that is responsible for monitoring vehicles going in and out of the parking facility; one or more smart gateways, based on the size of the car lot; and a broker, who takes responsibility for information dissemination in real time.
Firstly, the SecSPS framework can provide a real-time parking information and navigation service to users in search of parking spots, so that drivers can easily and quickly find vacant parking spaces. As a result, the time and gasoline consumed in search of free parking spaces can be reduced. It also helps in reducing carbon monoxide emissions, among other pollutants, as well as reducing traffic congestion in city centers.
Secondly, parking reservation is a key feature of any smart parking system. Therefore, our framework enables drivers to reserve a parking spot in advance, in order to ensure the availability of the vacant parking space by the time they arrive. On one hand, less time spent parking leads to less stress and happier customers, i.e., improves overall customer experience. On the other hand, this creates car lots that are easy to manage, while maximizing revenues and efficiency.
Thirdly, to the best of these authors’ knowledge, this is the first framework based on publish/subscribe (pub/sub) architecture, which is a very powerful way for IoT devices to interact. This architecture offers distributed, asynchronous, loosely-coupled many-to-many communication between message producers (publishers) and message consumers (subscribers). In our case, each parking facility (publisher) publishes its own available parking information under a topic, and drivers (subscribers) who are interested in that information find about it more or less instantly by simply subscribing to the same topic.
Finally, our framework provides a secure communication channel among end-points when sending data over the Internet by using a transport layer security (TLS) protocol. Unlike with HTTP, a pub/sub client need only establish a connection once per session, rather than re-establishing a connection with every request, which makes the TLS less costly in terms of CPU and bandwidth. Moreover, the framework guarantees confidentiality, integrity, and notification authenticity by encrypting the packet’s payload. In other words, it allows end-to-end encryption for the application data, even for untrusted environments. This approach does not require any additional custom mechanism on the broker side for decrypting the data in order to route the message to subscribers.
The reminder of this paper is organized as follows: Section 2 fills in the required background; Section 3 describes the system model, threat model, and design goals; Section 4 provides a detailed description of the proposed framework; Section 5 analyzes the security of our framework; and Section 6 covers the performance evaluation. Finally, we conclude our work in Section 7.
The pub/sub model is an alternative to the traditional client/server model, whereby a client communicates directly with an endpoint. It is a data-centric architecture, whereby messages are delivered to interested destinations without knowing the IP addresses of these destinations. In other words, it decouples the sender of a specific message (publisher) from another client, who is getting the message (subscriber), and allows communication via a third component (the broker). It also provides a greater scalability than the traditional approach because operations on the broker side can be parallelized and processed in an event-driven manner [
The broker can filter messages in various ways, so that each subscriber gets only the messages they are interested in [
In 1999, the Internet Engineering Task Force standardized a new cryptographic protocol called a TLS protocol. It primarily aims to achieve three main goals―authentication, confidentiality, and data integrity―which are critically important to securely communicate over the Internet. Confidentiality can be achieved using symmetric encryption with a strong block cipher, such as the advanced encryption standard (AES). On the other hand, authentication is accomplished with public-key cryptography. Finally, data integrity can be checked using message authentication code (MAC). In TLS, confidentiality and authentication are achieved through a series of messages called a “handshake”.
As shown in
・ RSA for key establishment and authentication;
・ a 128-bit AES in Cipher Block Chaining (CBC) mode for confidentiality; and
・ a secure Hashing Algorithm (SHA) for integrity.
After validation and negotiation of certificates are completed, both client and server exchange a secret key (session key). Finally, they exchange Finished messages to tell each other that, from now on, everything will be authenticated and encrypted. This handshake is officially complete when the client and server exchange the Finished messages [
In this section, we cover the main components of our framework, threat model, and design goals.
As shown in
The main objective of this component is to monitor each car lot and detect the presence of vehicles, in order to calculate the total number of free parking spaces
in each car lot at any time. To this end, each parking spot is equipped with a sensor to identify its status; however, there are various sensing technologies that can be reliably used to detect vehicles, technologies involving ultrasonic, magnetic, radar, and optical (infrared) sensors. In identifying the right technology, different factors must be taken into account, including size of target, sensing range, sensor mounting, accuracy, whether the sensor is indoor or outdoor, cost, and environmental conditions. That being said, it may be beneficial to combine two sensing techniques to achieve an advanced level of accuracy.
In general, IoT gateways perform various critical functions, such as device connectivity, protocol translation, data filtering and processing, security, updating, management, and more. Here, the smart gateway is responsible for receiving the states of parking spots from the sensor nodes, analyzing and encrypting this data, and sending them to the specific broker.
The broker is the heart of any pub/sub system. It is primarily responsible for receiving all encrypted messages from the smart gateway, filtering them, deciding who is interested in them, and then sending the messages to the subscribed clients. Since the application data itself stays encrypted all the time, and the broker has no way of looking into the encrypted data, it uses the unencrypted messages metadata (i.e., topic name) for routing. Note, the broker can be either public or private; for example, it can be owned by the Department of Transportation.
A client is any electronic device, from a micro-controller up to a fully-fledged server that is equipped with custom software that enables connecting to a broker over the Internet, such as a laptop, tablet, smartphone, or desktop. It can connect to the broker, subscribe to one or more topic(s), and be notified whenever there are new messages.
In [
This section is dedicated to identifying the goals that our framework should satisfy.
・ Correctness: If both the broker and the client follow the rules honestly, the client can get correct real-time parking availability information. Moreover, the client with a parking reservation is guaranteed to get a parking spot by the time he/she arrives. In other words, the framework must provide all its services in a correct manner when the rules are honestly followed.
・ Security: The framework must protect and guarantee the confidentiality and integrity of transmitted data, and keep it secure over the network. On one hand, the attacker cannot get the original data when given the encrypted messages. On the other hand, the framework can secure the communication channels between clients and brokers. Moreover, it should provide mutual authentication between the pub/sub clients and the broker.
In this section, we describe in detail the proposed framework, which can use any pub/sub messaging protocol, such as Message Queuing Telemetry Transport (MQTT). In general, we will use the term “users” when referring to drivers or vehicles. Initially, parking facility owners are required to register their identities to a trusted authority (e.g., governmental transportation authorities) before participating and launching secure services, in order to guarantee authentication and enable secure communications. The trusted authority makes sure attackers do not gain control of the network and protects sensitive data. Therefore, the parking facility owners need to send registration and connection requests to the broker’s security manager seeking the permission for providing service(s) (e.g., creating topics).
As mentioned earlier, the parking spot status information at each car lot is important, so that the broker can get and manage information in real time. Therefore, each parking space is equipped with a sensor (e.g., ultrasonic sensors), which is capable of sensing and detecting free spaces. When a vehicle is detected, a message is transmitted to the smart gateway to be interpreted and processed. This phase of the framework is known as the monitoring module.
The smart gateway aggregates all the readings from the sensors, processes these data, and calculates two things: the number of free parking spots for each floor, and the total number of free parking spots at the car lot with the corresponding vacant percentages. Next, it encrypts all this information with the secret key of the target topic, as will be described below. Finally, it sends the encrypted message to the broker for distribution and delivery, over TLS. Here, TLS is used to create a secure communication channel between the smart gateway and the broker, using the handshake mechanism. Using a secure channel makes it more difficult for third parties to intercept, or eavesdrop on, messages in transit. The smart gateway uses the broker’s certificate, which is issued by a trusted and secured authority, to verify its identity before sending a bit.
As mentioned earlier, our framework provides an additional security layer by supporting the exchange of encrypted messages (known as payload encryption). This approach ensures end-to-end encryption, preventing eavesdropping along the way, and spoofing of valid application data. In this approach, only the payload of the message is encrypted (PUBLISH packet payload) to ensure that there is no additional mechanism needed on the broker side for decrypting the data, in order to deliver the message to the subscriber. The broker uses the unencrypted packet metadata (e.g., topic name) for routing, the packet data itself stays encrypted, and the broker has no way of looking into the encrypted data, as shown in
The broker is responsible for ensuring that messages are delivered to the correct subscribers. In general, the broker performs several operations, including connect, disconnect, publish, subscribe, and unsubscribe. These operations are available for both users and parking owners who are authorized by the security agent of the broker. The security agent is an entity that is responsible for the security evaluation of each request sent to the broker (e.g., checking the resource access permissions).
When a parking facility is granted permission to create a topic, it only needs to send a “publish” request that includes the topic name and the message in encrypted format. The parking owner can define a set of access-control policies associated with their topics to restrict topic access, based on user attributes. These policies can be formally defined as a conjunction of attribute conditions {cond1Ù ... Ùcondn}. Each attribute condition is in the form of x, op, l>, where name x is the name of the attribute, op is a comparison operator, such as =, ≠, <, ≤, ≥, >, and l is the value of attribute x.
End-users are provided with a custom mobile application (Parking Application). This application enables them to find the available parking spaces near them, or near their final destination, get the right directions to the target parking spot, make a reservation, check the remaining parking time, and get notification when the parking time has expired.
First of all, the user is required to connect to the broker through the mobile app, which uses TLS. When the TLS handshake takes place, the client needs to validate the identity of the broker using its X.509 certificate. After the handshake process is completed, an encrypted communication between client and broker is established, and no attacker can understand the content of the communication. Next, the available car lots are displayed to the user, based on the user’s current location or final destination. Each car park is considered as an individual topic. The users can subscribe to one or more topics, based on their needs. After subscribing to a certain topic, they would start receiving messages from the corresponding car lot. Each topic provides real-time parking information, including parking rate, number of available regular parking spots, number of vacant accessible parking spots, and total number of parking spaces. The end-user will be notified whenever there is an update on the parking information. Note that the received messages will be encrypted, and the user needs to decrypt them using the topic password.
For smart parking systems, the parking reservation service is a key feature. Our framework allows a user to reserve a parking spot in advance to guarantee a free spot by the time the user arrives. After determining the target car lot, the driver can send a message to the broker under a subtopic named reservation. For example, let us assume that the topic corresponding to the chosen car lot is called t1, and the driver wants to reserve a parking space at it. Then he will need to publish a message under a certain topic, namely, t1/reservation. The published message contains different information, such as phone number, license plate number, type of parking spot, and parking time. By default, the car lot is the only subscriber to this topic. Therefore, the car lot will be immediately notified whenever there is a reservation request, and will decrease its total number of free parking spaces accordingly. Note that each car park maintains its own database, which stores all reservation requests. When the driver arrives at the entrance gate, they must be checked to see whether or not they have a reservation. If they have one, the gate opens and they can park in any free space. Otherwise, they will be rejected. Thus, the entrance gate unit must query the reservation database to accomplish this task. This verification process may be done using the user’s mobile parking pass.
In this section, we analyze the security of the proposed framework against different cyberattacks, and how it can counter these attacks. We assume that the end-user’s mobile device has a secure environment in which to perform cryptographic operations.
The intension of this type of attack is to steal sensitive information, such as username, password, and credit card numbers, by masquerading as a trusted entity. The proposed framework is an anti-phishing mechanism because there is no exist for static username and password during the authentication phase. In addition, there is no existing for username and password update. When the TLS handshake takes place, both client and broker authenticate each other using their X.509 certificates. As a result, the broker is able to verify the identity of the client, and vice versa, with no credentials required.
A man-in-the-middle (MITM) attack is a common type of cybersecurity attack that allows a malicious element to insert itself into a conversation between two parties, impersonate both parties, and gain access to information that the two parties are trying to send to each other. In general, a successful MITM execution has two distinct steps―interception and decryption. The first phase intercepts the network traffic before it reaches its destination. The second phase decrypts any two-way SSL traffic without alerting the user or application. Therefore, we need to provide some method of authentication for messages in order to be secured against MITM attacks. To block and prevent the risk of MITM, we rely on TLS to exchange messages over a secure channel. In such a structure, a client and broker exchange certificates, which are issued and verified by a trusted CA. Since we are assuming that this CA is trusted and secure, then the certificates, issued by the CA, can be used to authenticate the messages sent by the owner of such a certificate. Thus, our framework relies on a mutual authentication mechanism to thwart both ends of the MITM attack.
In this type of network attack, the intruder captures valid network traffic and then sends the same data transmission to its original destination, posing as the original sender. It is obvious that this kind of attack requires the ability to intercept the network traffic, as well as the ability to perform a masquerade attack. Moreover, the intruder will be able to perform the attack, even if the packet payload is encrypted. Therefore, our proposed framework uses the TLS to create a secure communication channel between two parties. Consequently, no attacker can eavesdrop on any part of the communication. This enables our framework to resist replay attacks.
For whatever reasons, some people and small businesses may prefer to use a free public broker; however, using a free public broker comes with a price. It increases the risk of being compromised by malicious hackers. If any broker is compromised, it literally opens a gateway for the attacker to gain access to sensitive information, and we can easily lose the data confidentiality and privacy of the user. Our framework takes that into account, and provides end-to-end encryption of the application data. In this scenario, if attackers get control over the broker, they still cannot look into the data itself because the data is encrypted. Thus, user privacy and confidentiality of encrypted messages can be guaranteed.
This type of technique (looking over the victim’s shoulder) is commonly used to obtain confidential information, such as username and password. It can also be performed remotely, using hardware assistance such as binoculars. This makes the static username and password not good enough for authentication. To prevent a shoulder-surfing attack, we use X.509 client certificates, which allow the client to be authenticated before establishing a secure connection.
As discussed earlier, our framework relies on TLS to secure communications over the Internet; however, using TLS comes with a price, as with any security measure. The main cost with TLS is that of resource consumption (e.g., CPU and network bandwidth), which is significantly higher compared to plain TCP. There are two main sources of such overhead. The first source is the TLS handshake process, i.e., the number of handshakes and the size of the messages transmitted in each handshake. The second source is related to the involved cryptographic operations while sending each message, i.e., the cipher suite employed. Our design is based on the key observation that the pub/sub client only needs to establish a connection once per session, however, unlike with other protocols, such as HTTP, which require a connection to be re-established upon every request. In other words, the TLS handshake takes place only once in the lifetime of the client.
To evaluate the impact of using TLS on the CPU utilization of a pub/sub broker, we conducted an experiment on the Eclipse Mosquitto broker using 10,000 real clients. For this experiment, we compare the CPU utilization for scenarios with and without TLS. We install the Mosquitto broker on a 2.5 GHz-processor computing machine using 16 GB of RAM.
Using elliptic curve cryptography (ECC) certificates instead of RSA certificates could significantly reduce the computation overhead. ECC creates stronger security keys with shorter key lengths than RSA does, which makes it faster and more efficient to implement.
Parameter | Value |
---|---|
Pub/Sub Clients | 10,000 |
Messages per second | 1000 |
Connections per second | 100 |
Quality of Service Level | 1 |
Cipher suite | TLS_RSA_WITH_AES_128_CBC_SHA |
Certificate key size | 2048 |
Security Level | RSA Key Length | ECC Key Length | Ratio |
---|---|---|---|
80 | 1024 | 160 | 6:1 |
112 | 2048 | 224 | 9:1 |
128 | 3072 | 256 | 12:1 |
192 | 7860 | 384 | 20:1 |
256 | 15,360 | 512 | 30:1 |
TLS session resumption is a technique that allows to reuse of an already negotiated TLS session after reconnecting to the broker, so that the client and broker do not need to do the full TLS handshake again. In short, this technique can be used to avoid a complete TLS handshake whenever a client reconnects, in order to reduce the overhead.
A load balancer plays an important role in traffic routing and traffic shaping for IoT solutions. One advantage of using it is the TLS offloading. In such a mechanism, expensive cryptographic operations take place on the load balancer, instead of the broker. This can increase the broker’s performance remarkably.
The pub/sub architecture depends on a broker as the central distributor of messages. To avoid the single-point-of-failure potential in such messaging systems, broker clusters are required. A broker cluster is a distributed system that acts as one logical broker. It contains multiple broker nodes that are typically installed
on different physical machines, and connected over a network. Thus, clients can connect to any broker node to resume sessions, and this increases the availability of the provided services. Also, it can easily scale from a few broker nodes to thousands. Another advantage of using a broker cluster is that it is fully resilient and fault-tolerant in case of infrastructure problems.
Cybersecurity is currently a growing issue in the IoT, which has tremendous benefits in smart city applications, such as smart parking systems. In this paper, we have proposed a secure and privacy-preserving framework for smart parking systems, utilizing the pub/sub messaging model. It ensures the confidentiality, integrity, and availability of real-time information by relying on two main security mechanisms―a secured communication channel via TLS, and end-to-end encryption for application data. It provides various services to the end-user, including real-time parking information dissemination, car park navigation, and parking reservation. Our framework is resilient to various security attacks, such as replay, man-in-the-middle, and chosen-plaintext attacks. It has a low overhead, due to the ECC-based certificates, which makes it ideal for securing IoT-constrained devices. In the near future, we will implement a prototype smart parking system, based on the proposed framework, on a large scale, in the real world, to evaluate its performance metrics more precisely.
The authors declare no conflicts of interest regarding the publication of this paper.
Alqazzaz, A., Alrashdi, I., Aloufi, E., Zohdy, M. and Ming, H. (2018) SecSPS: A Secure and Privacy-Preserving Framework for Smart Parking Systems. Journal of Information Security, 9, 299-314. https://doi.org/10.4236/jis.2018.94020