1.1. Intelligent Edge Environment Layers

• A new simple Resource Allocation Algorithm (RAA) is developed to run on a Resource Allocation Server (RAS). To enable mobile service, this algorithm has to be simple and fast.
• A new secure transfer protocol called the Resource Allocation Secure Protocol (RASP) is detailed. This will involve the use of cryptographic protocols such as ProVerif to show that the transfer protocol is safe.
• A secure access control system using capabilities, this is necessary to provide the Authentication, Authorization, Accounting (AAA).
• A new Secure Service Protocol is devolved using these mechanisms.
• The development of a new Service Management Framework (SMF) which can be used to manage applications and services in the IEE.
• The design of a capability-based Secure Service Protocol (SSP) to provide a complete framework for the IEE. The SSP is shown to be safe using Proverif.
• The implementation of a prototype SSP system using a Network Memory Server (NMS) to provide backing storage for a FUSE file system in a vehicular network.

3.1. Advertising Cloud Formulation

• Step 1: The resources in consideration are categorized as CPU, Network, Memory, and Storage: Resources (r) include: CPU (c), Network (n), Memory (m), and Storage (s).
• Step 2-4: These steps define the maximum capacity for each type of resource ($Cmr$), current allocation of resources ($Car$) and the available (unallocated) resources ($Cfr$) in the AC.
• Step 5-10: Condition Check and Advertisement: The condition checks if there are any free resources ($Cfr$). If there are free resources, the AC sends an advertisement of these resources and waits for a response. If there are no free resources, the system waits until resources become available when ($Cfr$) is greater than 0.

3.2. Receiving Servers Formulation

• Step 1: The resources CPU, Networks, Memory, Storage are members of resources(r).
• Step 2-3: Server SA${ }^{\prime }$s Requested resources are declared. Inclusion of an element Req_Res to a set of SAreqr resources.
• Step 4-5: If Requested resources are greater than 0, the cloud services needs to find the next best fit server.
• Step 6-9 Condition check before resource Migration: It checks if the AC has sufficient free resources to meet the Receiving Server’s request. If sufficient resources are available and greater than 0, the request is accepted, and the details are sent to the RAS for verification and processing. Else ignore the advertisement.

3.3. Resource Allocation Server

• Stage 2 3. R → SA: sign((CB, pkC, ResCB), pkS) [R → SA: The Registry approves the advertisement (Advc) and sends to the Receiving Servers (SA), detailing the free resources (Res freeCB) with its signature].

• Step 1-2 Verify Validity: The RAS server verifies whether it is a valid cloud and if Cloud resources are greater than the requested resources. If either condition false, then it rejects the request and updates CB that its an invalid server.
• Step 2-5 Pass Conditions: If the above conditions pass, then it sends an authenticated message to CB. This message confirms the approval of the resource migration.

• Step 1-2: RAS server verifies whether it is a valid server and if Cloud resources are greater than the requested resources which is not equalt 0 or not. If either conditions are false, then it rejects the request and updates SA that its an invalid Cloud.
• Step 2-5: If the above conditions pass, then it sends an authenticated message to SA.

4.1. General Notations

Table 2. RASP Table

1

Stage1: Advertisement:

Cloud CB actively advertises its resources Server SA receives advertisements from Cloud CB advertising Cloud B${ }^{\prime }$s resources with its identity CB.

1. CB → SA : Advc (CB, ResCB)

2

Stage2: Authentication of SA and CB as well as migration request and response:

Server SA first requests the RAS/Registry to authenticate Cloud CB and its resources. In Step 3, the Registry (R) authenticates Server SA. In Step 4, Server SA sends a migration request to Cloud CB. In Step 5, Cloud CB sends a request to the Registry to verify that Server SA’s request for resources is valid. In Step 6, the Registry replies to Cloud CB. In Step 7, Cloud CB sends the migration response back to Server SA.

2. SA → R : (SA, CB, ResCB)pkR

3. R → SA : sign((CB, pkC, ResCB), pkS)

4. SA → CB : aenc ((Ns, SA , ResSA), pkC)

5. CB → R : (CB, SA , ResSA)pkR

6. R → CB : sign((SA, pkS , ResSA), pkC)

7. CB → SA : aenc((Ns, Nc, CB), pkS)

3

Stage3: Migration transfer:

In Step 8, Server SA generates the session key (Ksc) to start the migration request. In Step 9, Cloud CB sends the migration initialization request. In Step 10, Server SA performs the migration transfer. In Step 11, Cloud CB sends an acknowledgment to Server SA. In Step 12, the service on Cloud CB (SB) updates the Registry on its new location.

8. SA → CB : aenc((Nc, Ksc), pkC)

9. CB → SA : enc ((M_Reqc, SA), Ksc)

10. SA → CB : enc ((M_Trfs, ResSA), Ksc)

11. CB → SA : enc ((M_Ackc), Ksc)

4

Stage4: Update of New service location to the Registry:

The new service SB is now running on Cloud CB and informs the Registry that it has been successfully migrated.

12. SB → R : aenc((SB, CB), pkR)

4.2. ProVerif an Overview

4.2.1. ProVerif Results

The results show that RASP can preserve the secrecy, authentication and key exchange of the service migration mechanism.

• Nonces are secured and not derived by the attacker: specific nonces (SNs, SNc, CNs, CNc) used in the protocol are not derivable by an attacker, ensuring their confidentiality. Each line indicates that the respective nonce cannot be compromised (is true).
• session key Results confirms that the session key (Ksc) and associated bitstrings (SNk, CNk) are secure from the attacker. The line "RESULT not attacker_bitstring (SNk []) is true." with Ksc also specifies the conditions under which this key is secure.
• Private keys Results confirms that the session key (Ksc) and associated bitstrings (SNk, CNk) are secure from the attacker. The line "RESULT not attacker_bitstring (SNk []) is true." with Ksc also specifies the conditions under which this key is secure.
• AuthenticationIt validates the mutual authentication between SA and CB. The use of inj-event indicates that the protocol verifies injective correspondence, meaning each event endSparam (or endCparam) has a matching beginSparam (or beginCparam), ensuring that both parties authenticate each other correctly.

Table 3. Query attacker ()

Table 3. Query attacker ()

Security properties	Server SA event	Cloud CB event
Session key	True	True
Private keys	True	True
Nonces	True	True
Event begin	True	True
Requested resources	True	-
Advc Resources	-	False

¹ Query attacker of results

By using symmetric session key (Ksc), the requested service is transferred to the new location CB. This research explored the development of a new resource allocation and secure service migration framework that encompasses the computing resources to migrate in cloud environments.

5.1. Capabilities in IEE

6.1. SMP Layers in Detail

• The Application Layer (AL) is the first layer of SMF. It runs on the mobile node and calls the service through the Service Management Layer (SManL). AL provides the service name, Service ID, and required QoS. When a service first comes to the SMF, it should have a unique ID for identification. The service name indicates the type of service being provided, such as CPU, Memory, or Storage. Lastly, the Application Layer must define QoS parameters for the required service, such as delay time, latency, bandwidth, reliability, and security.
• The Service Management Layer (SManL) is responsible for administering the mobile service, managing service subscriptions, and overseeing service delivery for the layers below it. Service subscription includes managing Service-Level Agreements (SLAs) and billing. Service delivery entails determining how services should move from one location to another. When this layer determines that a service should be migrated, it forwards this information to the service migration layer (SML).
• The Service Migration Layer (SML) manages migration requests from SManL and employs a Resource Allocation Security Protocol (RASP) to securely execute the migration process. Upon completion, SML informs SManL. The RASP, as described by [19], utilizes standard migration mechanisms like Docker, KVM, LXD, and Unikernels for the actual migration.
• Service Connection Layer (SCL): This layer monitors how clients connect to the services between the mobile node and the server. It reports to the SManL when the mobile node is no longer available due to handover to another network.

6.2. SSP Protocol—An overview

• Stage 1: Registration of the Service with the SMF: In Stage 1, the Cloud Management System (CMS) registers the Service with the SMF. This involves providing a list of servers and their public keys that will be running the Service. After this, in step 2, the SMF registers the Service and returns the Service ID (SERV ID) and the Service Capability (SERV CAP). Following this, the CMS initiates the servers to implement the Service on different machines and passes the Service ID and the Service Capability.

  1

  CMS → SMF: (Register Service (Service Details), (PK(SMF)))

  2

  SMF → CMS: (Service Registered (Service Details, SERV ID, SERV CAP), (PK(CMS)))

• Stage 2: The Application interacts with the SMF to get a server that implements the Service: In Stage 2, the Application interacts with the SMF to obtain a server that provides the Service. To utilize a service, an application must request the SMF to locate a suitable server. In step 3, the Application provides the Device Capability (DEV CAP), User Capability (USER CAP), Service Name, Service Version, and the Application’s public key running on the machine. In step 4, the SMF selects a server for that Service and contacts it using its public key, passing the Client’s DEV CAP, USER CAP, and IP address. In the subsequent step, the Chosen Server accepts the request. It generates a timed capability from the service capability, which expires in 60 seconds if the Application does not connect to the server. This SERV TIME CAP is a private proxy capability derived from the Service Capability and cannot be altered; only the USER CAP and DEV CAP can utilize the capability. The Chosen Server also provides its IP address and the TCP port of the Service using the public key of the SMF. In the final step of Stage 2, the SMF returns to the Application with DEV CAP, USER CAP, timed capability, the Server’s IP address, Service Port number, and public keys of the Chosen Server, enabling the Application to connect to the server.

  3

  APPL→ SMF: (Request service (Service Name, Service Version, DEV CAP, USER CAP, PK(APPL)), (PK(SMF))

  4

  SMF Chosen ->Server: (Usage request (DEV CAP, USER CAP, IP Client),(PK(SERV))).

  5

  Chosen Server-> SMF : SMF (Usage request accepted (DEV CAP, USER CAP, SERV TIME CAP, IP Server, Port Server), (PK(SMF)))

  6

  SMF→ APPL: (Request service accepted (DEV CAP, USER CAP, SERV TIME CAP, IP Server, Port Server, PK(SERV)), (PK(APPL)))

• Stage 3: The Application sets up a secure session with the Server. During Stage 3, the Application initiates a secure session with the Server by sending a session start request. This request includes the DEV CAP (device capability), USER CAP (user capability), SERV ID (server ID), a unique random number called Nonce of A (NA), the Server’s public key, and the SERV TIME CAP (server time capability). Nonce (NA) ensures that the session is unique on the Application side. In response, the Server sends back a session capability (CAP SESS), DEV CAP, USER CAP, NA, NB (another unique random number for the Server side), and a session key (SESS KEY). The SESS KEY is a symmetric key used only once to encrypt the details in one communication session.

  7

  APPL → Chosen Server: (Session Start Request (DEV CAP, USER CAP, SERV ID, SERV TIME CAP, NA)), (PK(SERV)).

  8

  Chosen Server→ APPL : (Session Start Request Accepted DEV CAP, USER CAP, CAP SESS, SESS KEY, NA, NB), (PK(APPL)).

• Stage 4: The Application gets service by using the CAP SESS key and encrypts using the SESS KEY In Stage 4 of the process, the application uses the CAP SESS key to access a service and encrypts data using the SESS KEY. The application sends a service request to the chosen server with the CAP SESS, Nonce (NB), and uses the SESS KEY. The server responds by sending CAP SESS, NA, and detailed results using the SESS KEY. NA ensures that the session is unique on the application side.

  9

  APPL → Chosen Server : (Service Request (CAP SESS, NB, Request Details)(SESS KEY))

  10

  Chosen Server → APPL: (Service Request Done (CAP SESS, NA, Result Details) (SESS KEY))

• Stage 5: The Application is finished and terminates the session In Stage 5, the application terminates the session by sending end requests to the chosen server with CAP SESS, nonce (NB), and session end using the session key. The server then terminates the session and revokes the CAP SESS capability to prevent replay attacks.

  11

  APPL → Chosen Server :(Session End Request Accepted (CAP SESS, Nonce (A), Session End)(SESS KEY)).

6.3. ProVerif results

6.4. Queries for Private Keys

• RESULT not attacker_skey(sksmf[]) is true.
• RESULT not attacker_skey(skcms[]) is true.
• RESULT not attacker_skey(skappl[]) is true.
• RESULT not attacker_skey(skS[]) is true.

7.1. Basic capability System Library(BCSL)

7.2. Make Fuxfs Multithreaded

7.3. Fuxfs Server

• Compile command: gcc -o Fuxfs_server Fuxfs_server.c
• Run command: ./Fuxfs_server 0.0.0.0

7.4. Fuxfs Client

• Compile command: gcc -Wall fuxfsmg.c `pkg-config fuse –cflags –libs` -o fuxfs -w -L./ libcapab.a -lpthread
• Run command: ./Fuxfs /tmp/fuse 0.0.0.0

7.5. Make Fuxfs Multithreaded

7.6. Multithread - SMF Commands

• Register Service: The function allows the service to be registered with the SMF. It collects information on the service, including the service name, the description of the service, the version of the service (i.e., 0 is the latest version), the TCP/UDP port number, and the service capability. Once the service has been successfully registered with the SMF, the SMF generates the global_id. The local_id is generated by the client.
• Register User: This function helps the new user register with the SMF. It collects information about the user, including the first name, surname, role, rank, and specialist, as well as the capability of the user to register. Once the user has been successfully registered with the SMF, the SMF will generate their global user ID. Each device will have a unique local device ID (generated by the SMF_THREAD) and a global device ID (generated by the SMF).
• Register Device: This register device function allows the devices to register with SMF. To register a device, the name of the device, the first name and surname of the device owner, and the device capability are also collected once the device is registered. Each device will have a unique local device ID and a global device ID.
• Add Server: This function helps the server be added to the required service. It also collects details about the server, including the server global ID given by NMS, the server’s name, the server location using the IPv4 address, and the server’s maximum load.
• Request Service : Once a service is registers with the SMF, the service can be requested by users who want to use it. Servers should provide this service to the requested applications. This function allows an application to request service. After the application sends a service request to SManL, SManL will provide the necessary parameters for the application to contact the server that runs the requested service.
• Migrate Service: This function allows the services to migrate to the required servers. It also collects details about the global service ID, the global user_id, and the global device_id and will set up the migration using Docker container technology. Once the migration is successful, a successful result will be returned to the caller.

7.7. NMS Part of FUSE as a Service

7.8. SMF - NMS as a Service