As mentioned in security consideration and requirements chapter, authentication is one of the most essential and primal security requirements which must be implemented in any proposed security architecture. Authentication is the process of showing and proving that the users, devices, and all components in the system are truly the ones that they claim. Authentication prevent any unauthorized users to access the system.
In case of the F2C system, all the devices and components such as cloud, fog nodes, and edge and IoT devices must be mutually authenticated. In order to provide authentication in the F2C scenario, two implementations are done such as:
1- In the mF2C project [155], the security architecture (CAUs) act as smart-gateways and bridge between cloud and devices at the edge for getting certificate and authentication process in the early stage.
2- The CAUs act as distributed authenticators and provide certificates and authentication process in their corresponding areas. In the following, both scenario will be illustrated and discussed.
8.3.1 CAUs in mF2C
The mF2C project [155], proposes a F2C combined architecture in a hierarchical way, where N-numbers of fog layers are allocated for facilitating service execution and delivery to the users. In this project, the proposed security architecture is implemented in iteration- 1 for facilitating authentication process. In Figure 13, the implemented authentication process with the help of CAUs is shown.
Authentication in mF2C is described as follows:
1- Initialization phase: In this process, all distributed CAUs authenticate and establish secure channel with certificate authority (CA) in the cloud.
1- CAU sends certificate signature request (CSR) and its id (CAU-id) to the CA. 2- CA sends CAU-id to the corresponding component such as id provider in cloud. 3- Id-provider in the cloud checks the CAU-id existence and it is validated and exists. 4- Id provider in cloud sends validation to the CA.
5- CA sends signed certificate to the CAU.
6- CAU and CA are authenticated and transport layer security (TLS) established for providing CAU-CA secure channel.
90 | P a g e
It is worth to mention, after fog nodes (see Fig. 7) selection in the fog areas is done, all the previous process will occur between each one of the fog nodes and the corresponding CAU, to provide fog node-CAU authentication and TLS establishment in initialization phase.
2- Edge device authentication process: 7- Edge device is registered in cloud.
8- Id provider in the cloud, generates device-id. 9- The id-provider sends device-id to the edge device.
10- In parallel, the device-id is sent to the CAU by id-provider for local id validation. 11- The edge device comes to the fog area and is discovered by the fog node.
12- The edge device sends CSR and device-id to the CAU. 13- CAU checks the device-id existence for validation.
14- If the device-id exists and it is validated then CAU sends CSR to the CA. 15- CA signs certificate and sends signed certificate to the CAU.
16- CAU sends signed certificate to the edge device. 17- In parallel, CAU sends device-id to the fog node.
18- Edge device and fog node are authenticated and establish TLS.
This authentication process uses distributed CAUs that act as smart gateway and bridges for id validation and facilitating communication between edge devices and CA.
91 | P a g e
8.3.2 CAUs as distributed authenticators
After developing the previous implementation, the security architecture deployed in the F2C system provides authentication in a distributed way rather than rely on the CA in the cloud. Whereas, in this new implementation, the F2C controller at cloud acts as CA for providing authentication and TLS establishment for distributed CAUs at the edge of the network. Then, all the CAUs act as distributed authenticator (distributed CA) for their corresponding fog areas. The Figure 14 illustrates the workflow for the implementation.
Authentication in distributed authenticators (CAUs) scenario is described as following:
1- Initialization phase: In this process, all distributed CAUs are authenticated and establish a secure channel with certificate authority (CA) in the cloud.
1- CAU sends certificate signature request (CSR) and its id (CAU-id) to the F2C controller.
2- F2C controller checks the CAU-id existence in the list for validation, if exists then, goes to the next step. (After id provider generate ids for CAU, it sends to the F2C controller.).
3- F2C controller sends signed certificate to the CAU.
4- CAU and F2C controller are authenticated and a transport layer security (TLS) is established for providing CAU-F2C controller secure channel.
It is worth to mention, after fog nodes selection (see Fig. 7) in the fog areas, all the mentioned process will occur for each one fo the fog nodes and the corresponding CAU, to provide fog node-CAU authentication and TLS establishment in the initialization phase.
2- Edge device authentication process: 5- Edge device is registered in cloud.
6- Id provider in the cloud, generates device-id. 7- The id-provider sends device-id to the edge device.
8- In parallel, the device-id is sent to the CAU by id-provider for local id validation. 9- The edge device comes to the fog area and is discovered by the fog node.
10- The edge device sends CSR and device-id to the CAU.
11- CAU checks the device-id existence for validation. If the device-id exists and is validated then, goes to the next step.
12- CAU signs the certificate and sends signed certificate to the edge device. 13- In parallel, CAU sends device-id to the fog node.
92 | P a g e
Figure 14. Authentication workflow in CAUs as authenticator
The both scenarios are implemented in our test-bed, the obtained results and comparisons between two scenarios are shown in section 9.1.