For validating the secure distributed data management proposal (Section 8.5), the implementation of all workflows (Figure 20, Figure 21, and Figure 22) is adapted to the smart city testbed. In the smart city testbed, there are different fog areas, in each area a fog node is selected for managing the fog area resources, service allocation, execution, and etc. In parallel, for each area a CAU is selected for handling security in their corresponding area. On the top of the smart city a cloud and F2C controller as master of CAUs is implemented.
The cloud services are hosted on the server machine with Intel Xeon family E5-2620 V4 series (clock speed @3GHz), 96GB RAM, 1TB Hard Drive running on Ubuntu 16.04LTS Linux, and the F2C controller is hosted in this machine. In the testbed, all the CAUs and fog nodes are relatively small computing devices. The CAUs are implemented in the Raspberry Pi3 B+ model. The Raspberry Pi3 B+ models are coming with Cortex A53 @ 1.4GHz processor, 1GB SD-RAM and each of them having a 64GB micro-SD card and running on Ubuntu 16.04LTS Linux. All the fog nodes are implemented on the Raspberry Pi Zero model. They are coming with 1GHz single- core CPU and 512MB RAM. For storage purpose, the 8GB microSD for each of the fog devices is considered.
Considering all the CAUs and the F2C Controller, we implemented the distributed database, over the network. For distributed data base creation over the CAUs and F2C controller, the containerized Apache Cassandra (Dockerized-Cassandra) is implemented. Basically, for performing the tests, the multi-datacenter, and multi-node based Cassandra cluster over the considering distributed framework have been implemented. All CAUs and F2C controller are implemented in Golang for providing the security functionalities. The authentication mechanism in CAUs is using X.509 public key cryptographic, data encryption and decryption by using AES algorithm and finally providing access control by using role-based approach.
In this section, a preliminary security analysis over the proposed secure distributed data management will be discussed and a penetration test is done over the TLS and authentication mechanism to illustrate that the security mechanism in distributed fashion works properly. Then, a comparison between the proposed architecture and traditional cloud is done to illustrate the efficiency of the proposed secure distributed database.
Security analysis: In the proposed architecture, the security functionalities such as authentication,
secure channel, encryption and access control are implemented.
1- Authentication: All distributed CAUs act as distributed authenticator using X.509 public key certificate with RSA that prevents any unauthorized user or device to enter in the F2C system. The distributed security provision rather than using a centralized approach gives some privileges such as: preventing man-in-the middle attack by decreasing the distance, because the authentication is performed closer to the users, also decreasing authentication’s time delay by bringing closer the authentication to the users, facilitating scalability issues by means of the distributed authenticator nodes in CAUs, bringing trust by using
115 | P a g e
distributed CAUs as authenticator nodes; and finally, facilitating QoS in fog nodes by decoupling the security functionalities in the CAUs node.
2- Secure channel: All CAUs provide secure channel over TLS communication after the authentication process. Therefore, it prevents any type of active or passive attacks during edge devices-CAUs-fog nodes-cloud communications because all data are passing over a secure channel
3- Encryption: Distributed CAUs are capable of doing encryption over data before storing them in their database by using AES. Therefore, all the data in CAUs storage are encrypted and then it prevents any type of database attacks.
4- Access control: CAUs consist on two components such as, CAU that provides security functionalities and Cassandra database for providing distributed secure data storage. CAUs have access control functionalities by access control role-based. Therefore, any device or user who wants to access to encrypted data stored in CAUs must satisfy access control role- based. This functionality prevents any unauthorized user or device to access the data stored in CAUs.
All the listed security functionalities are implemented in the security architecture (F2C controller and CAUs) to provide secure data management for the F2C system. The authentication and TLS communicates is tested by kali tools [160]. As illustrated in Figure 33, authentication and TLS communication provided by CAU are tested and proved completely secure.
116 | P a g e
Data transmission impact (For data storing and data retrieving): Here, a comparison between
traditional cloud secure data storing/retrieving and the proposed secure distributed database is performed and analyzed. The traditional cloud one uses the same workflow and algorithms that it is used in CAUs for sake of comparison between the centralized and distributed approaches. Then by comparing these two cases, the evaluation is showing the efficiency of the proposed model. So for that purpose, the test is performed on the various amount of distinct number of data packets. Each of the data packets contains information about the current state of participating resource information. The mainly consideration is the current state of participating resource information, for storing and retrieving purpose. The size of each data packet is mostly between the 10KB to 20KB. The whole measurement over both scenarios considers the whole workflow as described above that include security functionalities such as authentication, TLS establishment, encryption/decryption, access control, and finally data storing and retrieving.
Figure 34 illustrates the comparison of the obtained results for data storing between traditional cloud scenario (red line) and the proposed distributed data management (blue line). Obviously, cloud scenario has more network delay and bandwidth constraint because cloud is distanced and far away from the edge of the network. In the traditional cloud, the security functionalities cause delays not only because the distance, but also for handling the huge number of data going to the cloud. Therefore, the cloud scenario for storing data takes longer time compared to the proposed distributed data management. For sake of evaluation, the test performed is to store 1000 distinct data-packets for the both scenarios. Cassandra is using the consistent hashing algorithm to distribute the data over the cluster, so that also helps to speed up the data storing procedure. As illustrated in the obtained results (Figure 34) the proposed model is more efficient in terms of data transmission time compare to the cloud.
In Figure 35, data retrieving obtained results is shown for tested cloud scenario (red line) and the proposed model (blue line). For both scenarios, the data retrieving test is started with 10 thousand distinct data packets and ended-point for the evaluation is performed the test on 1.28 million data- packets. The obtained results on data retrieving in our proposed model shows that on 80 thousand distinct data packets, the response time has been raised up and after that for the next couple of tests, the query response time becomes more identical. The reason is because when increasing the number of data-packets from 80,000 to 1,60,000; then it might happen that, the data packets have not been uniformly distributed over the cluster. So, that is the main reason for jumping up the query-response time. Interestingly, after reaching more than 6,40,000 data packets, the query- response time is getting more constant, but with a bit higher response time. As illustrated in Figure. 31, traditional cloud has higher response time compared to our proposed model in data retrieving. When the data searching test on ten thousand distinct data-packets is performed, in the traditional cloud system; the response time is 6.9291 seconds. As the number of data-packets increases, the response time is also increased. After a certain amount of data packets (1,60,000), the query response time becomes more constant; because of the uniform distribution of data among the cloud resources. For the proposed architecture, as the number of data packets increase, the respond time is also increased. After 1.600.00 data packets (in 8.0340s), query response time become more constant.
117 | P a g e
Figure 34. Data Storing: Traditional Cloud vs CAU-based Distributed Database
118 | P a g e
According to the mentioned obtained result, the conclusion is that the proposed model is more efficient compared with the traditional cloud in terms of secure data storing and secure data retrieving in the F2C scenario.