Anis Bkakria

Lydia Brika
email: lydia.brika@irt-systemx.fr

A Framework for Privacy Policy Enforcement for Connected Automotive Systems

Keywords: Privacy enhancing technologies, Attribute-based encryption, Lightweight signature, Data tainting

The GDPR is a set of regulations designed to give users control over their personal data and applies to any connected object that processes such data. One of the most complex environments covered by the GDPR is the connected car, which has brought attention to the sensitive data processed by these vehicles. This data includes information about the driver or owner, the vehicle's environment, and the vehicle itself. Given the varying sensitivity levels of this data, it is important to offer users control over their data and privacy. To address this, we propose an end-to-end privacy preserving framework that ensures the integrity, confidentiality, and traceability of data related to user privacy within a connected vehicle. This framework combines data tainting for data traceability, lightweight signature for data integrity, and attribute-based encryption for confidentiality and access control to effectively enforce privacy policies set by both vehicle users and manufacturers. This approach is the first to offer end-to-end privacy and confidentiality policy enforcement for connected vehicles, covering data generation by sensors to the Transmission Control Unit.

I. INTRODUCTION

As everyday tools become increasingly interconnected to enhance user satisfaction, cars are no exception. They are entering a new era of connectivity, with connected cars communicating with applications' cloud, other connected vehicles, and even cities, in the age of connected and smart cities.

In a 2019 Washington Post article [START_REF] Fowler | What does your car know about you? we hacked a chevy to find out[END_REF], the extent of a connected car's knowledge about its user and with whom it shares that information was investigated. The destination of the data was found to be difficult for a regular car user to access, requiring the intervention of an engineer to hack into the car. The investigation revealed that the car stores a precise GPS record of the user's travel and stops, a log of all calls and caller IDs, as well as personal information such as addresses, emails, and even photographs. This data was collected solely on the infotainment computer, and the connected car has multiple computers. When a car user starts a new car, they are usually asked to accept the terms and conditions, but they are not informed about the type of data being stored or where it is being sent to. Therefore, no privacy policy is in place to safeguard the user's personal data. This work were supported by the french national research agency funded project AUTOPSY (grant no. ANR-20-CYAL-0008).

To address the privacy issue in connected cars, we suggest a comprehensive privacy-preserving framework that encompasses three key aspects: integrity, which involves using lightweight signatures between the physical layer (i.e., car sensors) and the processing layer (i.e., car computer); traceability, which involves tainting and tracking data using dynamic taint analysis; and confidentiality, which involves using attributebased encryption to ensure that data can only be deciphered by authorized services. This paper contributes to the development of this framework by:

• Defining an end-to-end privacy-preserving framework that enforces a privacy policy within a vehicular system, allowing users to preserve the privacy of their data based on their preferences. • Introducing the concept of a data sharing policy that empowers users to specify which services can or cannot access a particular type of data.

• Proposing an approach to enforce data sharing policies by combining data tainting, lightweight signature, and attribute-based encryption techniques. • Developing a customized taint tag model and taint propagation policy tailored to our specific needs and context. The remaining sections of this paper are organized as follows. Section 2 provides some background information on the technologies we will utilize. Section 3 offers an overview of related works in data tainting, specifically dynamic taint analysis. Section 4 introduces the concept of the "Data Sharing Policy," which categorizes data based on its sensitivity to a user's privacy. Section 5 presents our proposed approach. Section 6 evaluates our implementation. Lastly, Section 7 concludes the paper.

II. RELATED WORK

Recent advancements in smart cars technology have raised concerns regarding the enforcement of privacy policies in these systems. While several approaches have been proposed to address security and privacy concerns, few have specifically tackled the unique challenges of connected cars. One notable solution proposed by Gupta et al. [START_REF] Fowler | What does your car know about you? we hacked a chevy to find out[END_REF] is the formalized dynamic groups and attribute-based access control (CV-ABACG) model for smart car ecosystems. This approach employs a sophisticated access control mechanism to regulate user access and data sharing in connected car systems. However, the proposed approach supposes a weaker adversary model by assuming that the services and apps running in the car are not compromised. Future research in this area should explore more robust security mechanisms that can address a wider range of threat models.

In the upcoming sections, we review the various techniques that we will be using in our approach.

A. Data Tainting

Our focus is on monitoring data flow throughout the entire connected car system, which requires a comprehensive analysis approach. Since real-time data analysis is crucial, we prefer a dynamic taint analysis that can run code, taint it, and analyze the results concurrently. DECAF++ [START_REF] Davanian | DECAF++: elastic whole-system dynamic taint analysis[END_REF] is a well-known dynamic analysis tool for whole-system analysis. However, it does not support combining taint tags, which is necessary for our multi-taint tag approach. TaintDroid [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] is an extension to the Android platform that tracks sensitive data flow through third-party applications, using efficient multiple-marking taint tracking by combining multiple levels of information tracking. However, it is heavily dependent on the Android operating system, making modifications to it problematic. TEMU [START_REF] Yin | Temu: Binary code analysis via whole-system layered annotative execution[END_REF] is a dynamic analysis tool that enables whole-system finegrained monitoring, down to the instruction level, and dynamic binary instrumentation. It uses a shadow memory to store the state of each byte of physical memory and associated book-keeping information for each tainted byte. However, it stores 64-byte taint information in memory, which is too much for our purposes. Triton [START_REF] Saudel | Triton: A dynamic symbolic execution framework[END_REF] is a dynamic binary analysis library that uses symbolic execution to analyze a program and supports multiple taint tags. Panda [START_REF] Dolan-Gavitt | Repeatable reverse engineering with PANDA[END_REF] is a reverse engineering tool built on top of the system emulator QEMU [START_REF] Bellard | Qemu, a fast and portable dynamic translator[END_REF], which enables it to record and replay executions and perform bytelevel analysis. It stores taint tags as 32-bit vectors, similar to our desired taint policy.

B. Lightweight Signature

In our case, we are dealing with a car sensor as our context for signature. Since it is an IoT device with limited computational and memory resources, conventional signature schemes are challenging to use. Therefore, we are interested in lightweight approaches, particularly certificateless signature schemes and elliptic curve-based signature schemes, which focus on the computational cost and memory requirements.

There are four certificateless signature schemes that we compared. Du and Wen introduced a short CLS scheme [START_REF] Du | Efficient and provably-secure certificateless short signature scheme from bilinear pairings[END_REF] that uses a general hash function to improve the cost and computational efficiency compared to other CLS schemes. It is based on the inverse computational Diffie-Hellman problem and requires one scalar multiplication, a hash computation, and a pairing operation for signature generation. However, its resistance to side-channel attacks is not clear. Xiong et al. [START_REF] Xiong | Efficient and provably secure certificateless parallel key-insulated signature without pairing for iiot environments[END_REF] proposed a pairing-free CLS scheme based on the discrete logarithm problem that uses elliptic curves to maintain high efficiency. The signature is composed of five elements, but their size and key size are not mentioned. Signature computation requires one scalar multiplication, a hash computation, and a modular multiplication. Xu et al. [START_REF] Xu | Analysis and improvement of a certificateless signature scheme for resourceconstrained scenarios[END_REF] discovered that the scheme proposed in [START_REF] Thumbur | Efficient pairing-free certificateless signature scheme for secure communication in resource-constrained devices[END_REF] is insecure against forgery attacks and proposed an improvement using the elliptic curve discrete logarithm problem (ECDLP). The signature's size is the same as the group from which its elements are taken, and signature computation requires one scalar multiplication, two modular multiplications, and two hash computations. However, the authors do not mention the required key size or its resistance to side-channel attacks.

Although certificateless signature schemes show promise, most rely on the theoretical notion of the Random Oracle Model to prove their security. Additionally, most are based on bilinear pairing, which increases computational complexity since the relative computation cost of pairing is approximately twenty times higher than that of scalar multiplication over elliptic curve group [START_REF] He | An efficient identity-based blind signature scheme without bilinear pairings[END_REF].

Regarding ECC-based approaches, there are three schemes that appear suitable for our context. The first one, named SEMECS [START_REF] Yavuz | Ultra lightweight multiple-time digital signature for the internet of things devices[END_REF], is a multiple-time signature scheme that generates a 64-byte signature using one hash, one modular multiplication, and a modular subtraction with 32-byte private and public keys produced by the FourQ elliptic curve, which adopts Schnorr's key generation scheme [START_REF] Schnorr | Efficient signature generation by smart cards[END_REF]. The scheme has been proven secure with the discrete logarithm problem in the random oracle model. Additionally, since it utilizes the FourQ curve with a side-channel resistant module, the SEMECS scheme is also protected against side-channel attacks. The second scheme is NaCl [START_REF] Hutter | Nacl on 8-bit avr microcontrollers[END_REF], a high-speed software library that provides signature, encryption, decryption, message authentication, and other functions. It generates a 64byte signature using a 32-byte public key and a 64-byte secret key. The computation is performed with two hash operations and two modular multiplications using the Ed25519 signature scheme based on the elliptic curve Curve25519, making its security based on the elliptic curve discrete logarithm problem (ECDLP). Furthermore, the entire library needs only 17366 bytes of code, no static RAM, and less than 1350 bytes of stack memory, and all functions operate in constant time without containing secret-data-dependent branch conditions, making it immune to time attacks. The last scheme is the FourQ elliptic curve implementation as a library [START_REF] Liu | Fourq on embedded devices with strong countermeasures against side-channel attacks[END_REF]. It generates a 64-byte signature using a 32-byte key and one scalar multiplication, one hash, and one exponentiation. Its security complexity is based on the elliptic curve discrete logarithm problem (ECDLP).

C. Attribute-Based Encryption

Sahai and Waters [START_REF] Sahai | Fuzzy identity-based encryption[END_REF] introduced fuzzy identity-based encryption in 2005, which utilizes human-understandable information such as names as public keys, and views identities as descriptive attribute sets rather than character strings, a feature common to IBE schemes. In 2006, Goyal et al. [START_REF] Goyal | Attribute-based encryption for fine-grained access control of encrypted data[END_REF] proposed a generalized form of ABE that uses attributes to construct public keys, and access to data is regulated by an access policy expressed as a logical expression of the attributes. Bethencourt et al. [START_REF] Bethencourt | Ciphertext-policy attributebased encryption[END_REF] described the first ciphertext-policy attribute based (CP-ABE) scheme in 2007, an ABE scheme that uses treebased access policies embedded within the cipher. In contrast, a user's secret key contains a set of attributes that can be used to decrypt a ciphertext if it matches the ciphertext's access policy.

Building on the tree-based CP-ABE scheme, Goyal et al. [START_REF] Goyal | Bounded ciphertext policy attribute based encryption[END_REF] proposed a design that suffered from efficiency issues as every attribute had to be copied for every position in the access tree. This efficiency problem is a significant challenge in CP-ABE, primarily because computation costs increase linearly with cipher size, but Hernaz et al. [START_REF] Herranz | Constant size ciphertexts in threshold attribute-based encryption[END_REF] proposed constantsized ciphertexts to address this issue. In the context of access control in cloud environments to ensure data confidentiality and purpose limitation, the primary research focus in ABE is on CP-ABE, with many surveys focusing on ABE schemes in this context [START_REF] Lee | A survey on attribute-based encryption schemes of access control in cloud environments[END_REF]- [START_REF] Zhang | Attribute-based encryption for cloud computing access control: A survey[END_REF].

III. SYSTEM ARCHITECTURE

The proposed system architecture is composed of three entities: the vehicle driver, the vehicle manufacturer, and the services that use the data generated by the vehicle. The vehicle driver entity represents the user of the vehicle who desires to utilize specific services while ensuring their privacy. The data that are required by these services are the only information that should leave the vehicle, and sensitive information should be protected. The vehicle manufacturer's objective is to enable certain services, such as predictive maintenance, to access the data generated by the vehicle, but sensitive data that could reveal trade secrets should remain within the vehicle. The services that use the data generated by the vehicle are the third entity, which provides various services based on the vehicle's data. The proposed architecture addresses the privacy concerns of vehicle drivers while enabling the vehicle manufacturer and service providers to utilize vehicle-generated data for various applications.

A. Architecture of the considered vehicles

To provide a detailed understanding of our proposed solution, we present the structure of the futuristic connected car model that we are working on. Our model comprises sensors positioned all around the car's structure, which receive data from the outside environment. The sensors capture various data, such as temperature, humidity, pressure, and sound, among others.

The captured data from the sensors are then transmitted to a Central Computer, which is a high-performance computer (HPC) installed in the car. The HPC processes the data and performs various operations on it to provide insights and make decisions based on the captured information. The HPC uses machine learning algorithms to analyze the data and can identify potential issues with the car, such as identifying a fault in the engine or warning the driver of a hazardous situation.

The transmission of data from one location to another within the car is made possible by using electrical components known as electronic control units (ECUs). These ECUs are designed to handle specific tasks within the car, such as monitoring the engine's performance, controlling the braking system, and managing the car's entertainment system.

Furthermore, if any data needs to be transmitted outside of the car, it must pass through a Transmission Control Unit (TCU), which is the only exit point for data. The TCU sends the data to a data lake, which is a centralized storage system that stores all the data collected from the car. Various services can access the data lake to retrieve data as required, such as a mechanic who needs to diagnose a problem with the car or an insurance company that requires information about the car's usage.

B. Security Hypothesis and Adversary Model

To gain a deeper understanding of our solution's security requirements, we focused on the adversary model within our context. With our solution comprising of three levels -data tainting, signature, and attribute-based encryption -we assume the presence of a highly capable adversary within the car who could potentially make the following modifications to our proposed solution:

• Installing a malicious app on the central computer to access and collect data about the user or the vehicle. • Tampering with data or taint tags between sensors and the central computer, potentially exposing sensitive data due to modified sensitivity levels. • Arbitrarily deciding which data gets sent out of the car, whether it should be encrypted, and who can access it from the TCU. By defining the adversary model, we gain a better understanding of the context and the effectiveness of our solution against potential attacks. Additionally, it is worth noting that our solution incorporates advanced futuristic technologies in vehicular systems, with sensors having computational abilities to taint and sign and all car computers centralized in one.

IV. APPROACH

A. General Overview of the Solution

Developing an end-to-end privacy-respecting framework involves multiple steps and requires combining various individual solutions, each with its unique set of requirements. To provide a better understanding of our work, we present an overview of the solution we offer.

Our solution addresses every component of the car to create a comprehensive end-to-end privacy-respecting framework that safeguards data from the moment it enters the car to when it leaves the data lake for processing by services. At the sensor level, data is tagged according to its sensitivity level concerning user privacy. This sensitivity level is predetermined by the car user and constructor, as outlined in the "Sharing Policy" section. Once data is tagged, a taint tag is attached to follow it, and both the data and the taint tag are signed to ensure their integrity before leaving the sensor.

Upon arrival at the central computer, both the data and the taint tag's signatures are verified. If the verification is valid, we can track data as it flows within the car and gets used by installed apps on the central computer. This helps us understand how data is processed and provides full visibility of where it was used, who used it, and whether it was combined with other data. Furthermore, we can be alerted if tainted data attempts to leave the car by filtering data at the Transmission Control Unit (TCU).

To protect the data, we use attribute-based encryption, which ensures confidentiality and access control of the data. The encryption process involves encrypting data using an access policy that specifies who can decrypt the data, which is also predetermined by the "Sharing Policy." This approach guarantees that only authorized users can access the data and provides an additional layer of protection against potential data breaches.

Overall, our end-to-end privacy-respecting framework comprises various solutions, each with its unique set of requirements, to create a comprehensive approach that safeguards user privacy and data integrity throughout the car's entire data processing cycle.

V. SHARING POLICY

In order to protect user privacy, it is essential to have a mechanism that can identify different types of data and classify them according to their sensitivity. This mechanism should enable us to taint, sign, and encrypt data effectively. To achieve this, we require a tool that combines a privacy policy for the car user and confidentiality rules for the car manufacturer. By doing so, we can define a data sharing policy that takes two inputs: the user's input and the constructor's input. The two inputs, user input and manufacturer input, can be further divided into two categories: privacy requirements and functional requirements.

Privacy requirements refer to the specific privacy preferences of the car user and the confidentiality requirements of the car manufacturer. For example, the car user may want to keep the location of the car private during specific periods of the day, and the car manufacturer may have information generated by specific car sensors that could reveal confidential construction secrets that they do not want to share with anyone.

Functional requirements refer to the specific needs of the car user and car manufacturer for the proper functioning of the car. For example, the car user may have installed a GPS app that requires access to the car's location data, while the car manufacturer may have a maintenance app that requires access to the car diagnosis.

By categorizing these inputs into privacy and functional requirements, we can develop a comprehensive data sharing policy that outlines how each type of data should be handled, protected, and shared between the user and the manufacturer. This policy should take into account the unique needs and concerns of both parties and ensure that the privacy and confidentiality of the user's data are always maintained.

A. Policy Specification

The inputs of the data sharing policy will be rules that are decided by the manufacturer and the vehicle user. These rules are defined in the following definitions.

Definition 1 (Simple Sharing policy rule): Given a data type t, a set of services S, and a sharing decision d ∈ {allow, deny}, a simple sharing policy rule (SSPR) is specified according to the following format: t, S → d {x} where x ∈ {u : user, m : manuf acturer} denote the entity that specified the rule.

Informally, a sharing policy rule specifies whether a data item having a data type t can or cannot be shared by the set of services S. It is noteworthy that there exists no necessity to differentiate functional requirements from privacy and confidentiality requirements, as such distinctions can be made based on the decisional outcomes of corresponding rules. Specifically, rules relating to functional requirements are indicative of authorization, while those concerning privacy and confidentiality pertain to prohibitive measures.

In practical scenarios, some data types may not inherently possess sensitivity; nevertheless, they can pose a significant threat to user privacy when combined with other data types. Location data, for instance, exemplifies such data as it may be regarded as non-sensitive when viewed in isolation. However, when associated with other data types, such as a name or timestamp, the data can acquire sensitivity and potentially compromise user privacy.

Definition 2 (Composition Sharing policy rule): Given a set of data types T = {t 1 , • • • , t n }, a set of services S, and a sharing decision d ∈ {allow, deny}, a composition sharing policy rule (CSPR) is specified according to the following format:

T , S → d {x} where x ∈ {u : user, m : manuf acturer} denote the entity that specified the rule.

Informally, a CSPR governs the simultaneous sharing of a particular set of data types with specific services. It should be noted that while an authorization composition rule can be transformed into a set of SSPRs, a prohibition composition rule cannot be expressed as a set of SSPRs. Instead, it requires that a specific set of data types should not be shared concurrently with the set of considered services to ensure compliance with the established data sharing policies. In addition, it can be observed that an SSPR can be represented as a CSPR (Composition Sharing Policy Rule) with a set of data types, denoted as T , containing only a single data type. Hence, in the sequel, we adopt the CSPR specification (as defined in Definition 2) as a means of representing both SSPR and CSPR. To refer to the sharing policy rule in either case, the notation SPR is employed uniformly.

B. Conflict Management

As sharing policy rules are to be specified by both the vehicle user and the vehicle manufacturer, the overall sharing policy to be applied may contain conflicting sharing rules. Informally, this happens when a data type is authorized (resp. denied) to be shared with specific services by the vehicle manufacturer, while being denied (resp. authorized) to be shared with the same services by the vehicle user. Such conflicting rules can be defined as follows.

Definition 3 (Conflicting rules): Given a sharing policy P composed of the set rules r i : T ri , S ri → d ri (i ∈ [1, n]). A conflict, denoted by (r, R), occurs in P if and only if: ∃r ∈ P, ∃R ⊂ P : ∪ r ′ ∈R T r ′ = T r and S 1 ∩ S 2 ̸ = ∅ and d r = deny and d r ′ ∈R = allow we propose a solution to manage such conflicts effectively. Our solution comprises four rules that take into consideration the origin of the data type to be shared and the criticality of the service to which the data will be disclosed. The origin of the data is categorized into two classes: data that originates from the usage of the car by the user, such as geographic position, acceleration, and speed, and data that is related to the car components themselves, such as the serial number of the car, the types of the used ECUs, and the version of the firmware used by the ECUs. In addition, we classify services into two categories: critical services that are essential for the proper functioning of the vehicle, such as predictive maintenance and firmware update services, and non-critical services that refer to features or functions that are not essential for the safe operation of the vehicle, such as location-navigation and infotainment services.

Conflict management rules are described as following:

• Rule 1: Any data type that is required by a critical service should be authorized. Formally, this implies that when faced with conflicting rules (r, R) concerning a given critical service S * , where ∀r i ∈ R : T ri , S * → allow and r : T r , S * → deny, only the rule r i ∈ R should be deemed valid.

• Rule 2: In instances where a data type pertaining to vehicle data is mandated for sharing with a non-critical service by the manufacturer, while simultaneously being restricted for sharing with the same service by the vehicle user, it is deemed appropriate to authorize such data sharing in accordance with the manufacturer's rules. This rule is based on the premise that vehicle data has the potential to reveal information about the vehicle, while posing negligible risks to user privacy. Formally, given conflicting rules (r, R) concerning a data type T {v} related to the vehicle and a non-critical service S, where r :

T {v} r
, S → deny {u} and ∀r i ∈ R : T {v} ri , S → allow {m} , only the rules r i ∈ R should be considered.

• Rule 3: In the case where a vehicle-related data type is subject to restrictions by the manufacturer for sharing with non-critical services, yet authorized for sharing with the same service by the vehicle user, such data sharing is prohibited in adherence to the manufacturer's regulations. This rule is established on the premise that vehicle data possesses the capability to disclose information regarding the vehicle, which can be exploited by competitors or adversaries. Formally, given conflicting rules (r, R) concerning a data type T {v} related to the vehicle and a non-critical service S, where r :

T {v} r
, S → deny {m} and ∀r i ∈ R : T {v} ri , S → allow {u} , only the rule r should be considered.

• Rule 4 In the case where a vehicle usage-related data is type is authorized to be shared with non-critical data service by the manufacturer, but denied by the user, such data sharing should be prohibited according to the need of the user. This rule is established on the premise that vehicle usage-related data can disclose significant information about the vehicle user. Formally, given conflicting rules (r, R) concerning a data type T {u} related to the vehicle usage and a non-critical service S, where ∀r i ∈ R : T {u} ri , S → allow {m} and r : T {u} r

, S → deny {u} , only the rule r should be considered.

C. Policy Enforcement

In order to enforce policies in the context of connected vehicle, we explore two potential solutions: a policy enforcement approach that focuses solely on outgoing data, and a more comprehensive approach that encompasses both in-vehicle and outgoing data. A comparative overview of these solutions are provided in Figure 2.

1) Outgoing Data Policy Enforcement(OPE):

We introduce a novel approach to enforce data sharing policies in a vehicle's ecosystem. As per this policy enforcement strategy, we consider that it is unnecessary to enforce data sharing policies as long as the data remains inside the vehicle. However, to ensure that the policies are enforced correctly, it is crucial to have a system in place that can trace each data item's journey from the sensors to the entity responsible for sharing them with external services.

To achieve this objective, we propose a combination of data tainting and lightweight digital signatures. At the sensor level, we associate each data item with a specific tag that describes its data type using data tainting. Then, we use digital signatures to link both the data items and their tags in an verifiable and immutable way. Thereafter, we define a taint propagation policy that states how the different tags should be propagated inside the vehicle architecture.

To reduce to the best the amount of data items that should be tracked in the vehicle system, we need to focus only of the tags that represents the data types that are concerned with the specified data sharing policy. To meet this objective we classifies data types into three classes:

• Non-sensitive data type: non sensitive data types are those who are not concerned by any data sharing rules. Formally, given a data sharing policy P, a data type t is sensitive if and only if ∄r ∈ P such that t ∈ T r . • Sensitive data type: This class concern the data types that matches at least a data sharing rule. Formally, given a data sharing policy P, a data type t is sensitive if and only if one the following conditions hold: (i) ∃r ∈ P: {t} = T r and d r = deny (ii) ∃r ∈ P: t ∈ T r and d r = allow

• Quasi-sensitive data type: This class contains data types that are considered in the sharing policy but do not match any sharing rule when used alone. Formally, given a data sharing policy P, a data type t is quasi-sensitive if and only t is not sensitive and ∃r ∈ P such that {t} ⊂ T r and d r = deny. Thanks to the previous classification, we were able to define taint propagation policy describing how the taint tags need to be propagated. The latter is composed of the following three rules:

• 1 st rule: If a sensitive data type is combined with any other data type, the resulting data value will be tainted with a sensitive tag. • 2 nd rule: The non-sensitive data acts as a neutral element, meaning that the result inherits the taint tag of the second operand regardless of its data type, unless the second operand is also non-sensitive, in which case the result is non-sensitive and untainted. • 3 rd rule: In the case where two quasi-sensitive data items, denoted as t 1 and t 2 , are combined, the tag associated with the resulting data {t 1 , t 2 } item will contain both initial tags and will remain a quasi-identifier as long as the combination {t 1 , t 2 } is not sensitive.

The Transmission Control Unit (TCU) is responsible for enforcing a specified data sharing policy when a tainted data item is to be shared with a service outside the vehicle. The policy is enforced according to the following rules:

• If the data item is sensitive, and both its associated data types denoted as t 1 , • • • , t n and the intended service match a specific rule in the sharing policy that authorizes sharing, the data item will be encrypted using attributebased encryption to enable access only to the target service. Conversely, if the matched rule prohibits sharing, the data item will be dropped, and the service will not access it. • If the data item is quasi-sensitive or non-sensitive, none of the sharing policy rules match the associated data types. Consequently, the data item will be shared or dropped.

2) In-Vehicle and Outgoing Data Policy Enforcement (IOPE): This policy enforcement strategy assumes that applications running inside the vehicle may share sensitive or private information with remote services, rendering them untrustworthy. Consequently, these applications cannot access data types unless explicitly authorized by the specified data sharing policy.

Similar to the outgoing data policy enforcement strategy, the same data classification, data tainting, and taint propagation policies are employed. However, in this strategy, data sharing policy rules are enforced at two levels. First, the Data Authenticator is used to authenticate and verify the integrity of the taint tags associated with each data item. Then, prohibition rules are enforced to prevent unauthorized access to data types that are not permitted by the sharing policies. Second, upon transmission of a data item from an application to a remote service, attribute-based encryption is implemented at the TCU level to ensure that solely the intended data service is authorized to access the shared data item.

VI. IMPLEMENTATION AND EVALUATION

In this section, we provide details about the implementation of our framework.

To implement the digital signature and verification functionalities used by our framework, we employed an implementation of the Ed25519 signature scheme [START_REF] Bernstein | Highspeed high-security signatures[END_REF] based on the elliptic curve Curve25519 [START_REF] Bernstein | Curve25519: new diffie-hellman speed records[END_REF]. This implementation was provided by the salty library [START_REF]Github -ycrypto/salty: 25519 for cortex-m4 microcontrollers[END_REF], which is a high-speed software library specifically designed for resource-constrained IoT devices and written in the C and Rust programming languages. It is worth mentioning that in all conducted experiments, the reported results are derived from 1000 executions.

In order to assess the potential latency impact of digital signature usage, we conducted an experimental evaluation of the signature overhead on a Cortex-M4 microcontroller, using data items of various sizes. The results of our experiments are illustrated in Figure 3. The experiments conducted demonstrate that the signature process takes around 8 ms to sign an integer and up to 12 ms to sign larger objects encoded in 2 10 bytes. When implementing the outgoing data policy enforcement strategy, it is necessary to track any contaminated data items as they undergo processing across various applications. Hence, we investigate the effectiveness of our newly defined taint tag and taint propagation rules. To achieve this, we compared existing dynamic taint analysis tools that offer a byte-sized taint tag and code that can be modified to implement our approach. After conducting a thorough analysis of available tools, we determined that Panda [START_REF] Dolan-Gavitt | Repeatable reverse engineering with PANDA[END_REF] is the most suitable tool for our purposes. It is an open-source platform for dynamic analysis that are based on the whole system emulator QEMU 341 ns 320 µs 311 2 12 1,31 µs 1,36 ms 359 2 14 5,46 µs 2,14 ms 392 2 16 17,46 µs 7,50 ms 430 2 18 72,46 µs 36,5 ms 504 2 20 231,3 µs 132 ms 571 DT: Data tainting implementation. [START_REF] Bellard | Qemu, a fast and portable dynamic translator[END_REF]. It offers dynamic taint analysis in the form of plugins that can be used to propagate and analyze taints on a live system. Table I presents the measured multiplicative execution time overhead resulting from the implementation of our taint propagation policy using Panda, represented in terms of the number of instructions executed by the application processing the tainted data item. The reported multiplicative execution time overhead measures how much slower an application runs due to the usage of data tainting.

Table 1 shows that when using the data tainting propagation implementation, the execution time is approximately 320 times slower compared to when it is executed without data tainting propagation. Similarly, for applications with 2 20 instructions, the execution time is 571 times slower when using data tainting propagation. While this level of overhead may be tolerable for relatively small applications, it becomes increasingly unacceptable for larger applications. Larger applications with more complex codebases and greater numbers of instructions will experience a greater slowdown, resulting in unacceptably long execution times.

Always in the context of the outgoing data policy enforcement strategy, we conducted an assessment of the impact of enforcing a fine-grained access control policy on latency. It should be noted that as the policy enforcement is expected to be carried out by the TCU, the two following experiments was conducted on a Raspberry Pi 3, featuring a Quad Core CPU clocked at 1.2 GHz and 1 GB of RAM. The evaluations was carried out in two stages.

Firstly, we measured the time required to make a sharing decision (either allow or deny), as a function of the number of rules in the sharing policy. Figure 4 illustrates that the time required to get a decision (i.e., allow or deny sharing) from a sharing policy increases linearly with the number of rules in the policy. For a large policy composed of 10 3 sharing rules, the average time needed to get a decision is 914 µs.

Subsequently, we investigated the impact of attribute-based encryption on latency when sharing data with specific services, with consideration given to the size of the data item to be shared. In line with modern Attribute-Based Encryption (ABE) schemes, the data is safeguarded through a blend of ABE and symmetric encryption techniques. This entails initially encrypting the data using semantically secure symmetric encryption with a randomly generated symmetric key, which is subsequently encrypted using an ABE scheme. The results are depected in Figure 5 and shows a quasi-constant encryption latency as a function of the size of the data item to be encrypted. For a large data item of size 1 MB, the average encryption time is 846 µs. We will now evaluate the overall latency resulting from the two proposed strategies for enforcing sharing policies. The primary distinction between the two approaches lies in the propagation of taint at the application level. To compare them effectively, we analyze the overall latency as a function of the number of instructions the application under consideration. It is worth noting that the considered data items are GPS locations, each with a size of 8 bytes. The obtained results are depicted in Figure 6. The above analysis reveals that for relatively small applications (less than 2 12 instructions), both strategies exhibit similar latencies. However, for larger applications, the latency grows exponentially as the number of instructions in the considered application increases. In the context of this experimentation, the examination of an application executing 2 24 instructions (specifically, the process of launching a browser) reveals that the overall latency remains within 28 milliseconds when employing the IOPE strategy. Conversely, the latency exceeds 1 second when utilizing the OPE strategy.

Based on the conducted experimentation, several key takeaways can be derived. Firstly, the Object Policy Enforcement (OPE) strategy offers greater flexibility from a utility perspective, as it allows the sharing policy to be applied only when data is intended for publication. However, this flexibility comes at the cost of significantly increased latency, primarily due to the extensive taint propagation within the utilized application. Consequently, the Input-Output Policy Enforcement (IOPE) strategy appears to be more appealing for deployment in real-world environments. IOPE strikes a balance between maintaining reasonable latency levels and ensuring effective enforcement of sharing policies, making it a more practical choice.

VII. CONCLUSION

In this paper, we propose an end-to-end privacy-preserving framework to establish a robust mechanism for enforcing privacy policies, allowing vehicle users and manufacturer to maintain control over the privacy/confidentiality of their data based on their preferences. The introduction of the data sharing policy concept empowers users by enabling them to specify access permissions for different services, enhancing their ability to manage and protect their data. To cater to the specific requirements and context of the framework, a customized taint tag model and taint propagation policy were developed, ensuring efficient and effective privacy preservation. We further propose two approaches for enforcing data sharing policies, employing a combination of data tainting, lightweight signature, and attribute-based encryption techniques. Finally, we conduct an extensive experimental evaluations to assess the efficiency and scalability of the proposed sharing policy enforcement strategies.

Fig. 1 .

 1 Fig. 1. Considered architecture of a connected vehicles

Fig. 2 .

 2 Fig. 2. Policy enforcement strategies

Fig. 3 .

 3 Fig. 3. The time needed for a Cortex-M4 microcontroller to sign a data item as a function of its size.

Fig. 4 .

 4 Fig. 4. The time needed to enforce the sharing policy as a function of the number of rules in the policy.

Fig. 5 .

 5 Fig.5. The time needed to encrypt a data to be shared using ABE as a function of the size of the data item.

Fig. 6 .

 6 Fig.6. Comparison of overall latency for two proposed sharing policy strategies as a function of the number of instructions in the considered application.

TABLE I MULTIPLICATIVE

 I EXECUTION TIME OVERHEAD: A MEASURE OF HOW MUCH SLOWER A PROGRAM RUNS DUE TO THE USAGE OF DATA TAINTING.

	Number of	Execution time	Overhead
	instructions	without DT with DT
	2 10


Pedro Braconnot Velloso
email: pedro.velloso@lip6.fr

David Cordova Morales

Thi Mai

Trang Nguyen
email: thi-mai-trang.nguyen@lip6.fr

Guy Pujolle
email: guy.pujolle@lip6.fr

BASICS: A Multi-Blockchain Approach for Securing VM Migration in Joint-Cloud Systems

published or not. The documents may come

I. INTRODUCTION

Cloud computing is a consolidated technology in which cloud operators deploy a set of physical servers that offers computing resources to their clients. Hence, these computer resources are often provided as virtual machines. The main idea consists of dividing the resources of physical servers into virtual machines that can be dynamically allocated according to the demand. Besides this basic concept, clouds from different operators might cooperate not only to scale resources for handling short-term spikes but also to provide adequate responsiveness and usability to clients distributed worldwide [START_REF] Grozev | Inter-cloud architectures and application brokering: taxonomy and survey[END_REF]. Hence, several solutions have been proposed to deploy cross-cloud cooperative architectures, for instance, Federated clouds [START_REF] Lee | Cloud federation management and beyond: Requirements, relevant standards, and gaps[END_REF], Joint-cloud [START_REF] Shi | The inherent mechanism and a case study of the constructional evolution of the JointCloud ecosystem[END_REF], and Edge federation [START_REF] Cao | Edge federation: Towards an integrated service provisioning model[END_REF].

In this context, the migration of virtual machines plays a key role in bringing even more flexibility to cloud systems. VM migration allows cloud operators to perform server maintenance, load balancing, energy management, reduce service delay, avoid SLA violations, and provide security. Despite all its benefits, it is clear that VM migration introduces overheads to all the involved roles. Thus, several works try to improve the migration performance [START_REF] Noshy | Optimization of live virtual machine migration in cloud computing: A survey and future directions[END_REF]. In addition, there are other issues to consider at the time of VM migration, such as respecting the SLA of the original VM [START_REF] Ghumman | Continuous and distributed monitoring of cloud slas using s3lacc[END_REF], how to monitor SLA violations by different clouds [START_REF] Falasi | A model for multi-level SLA monitoring in federated cloud environment[END_REF], ensuring the same configuration in the new server, how to trust in VM migrations [START_REF] Ahmed | Trust evaluation in cross-cloud federation: Survey and requirement analysis[END_REF], or preventing infected VM migrations. This last issue is a challenge because one must keep the VM safe from attacks while it is running and assure the VM is not modified before arriving at the destination. During migration, a VM is vulnerable to DDoS attacks, loss of data integrity, confidentiality, unauthorized access, and virus contamination [START_REF] Janjua | Enhanced secure mechanism for virtual machine migration in clouds[END_REF].

Hence, the main goal of this paper is twofold: (i) assuring the integrity of virtual machines during migration and (ii) keeping immutable records of VM migrations. Hence, our work is not concerned with protecting nor detecting VM attacks or malfunctioning. Instead, we aim to ensure that a VM has not been tempered after leaving its original server by taking a snapshot of its ultimate status using a one-way cryptographic function. In addition, upon the detection of a problem with a VM, cloud operators will be able to track down all the servers that have hosted this VM following all the migration history.

In this paper, we propose to benefit from the advantages of blockchain technology, specifically the immutability and high availability to achieve our goals. We consider a Jointcloud scenario, in which several clouds from different tenants might exist. Virtual machines might migrate locally, i.e., inside their own cloud, or to an external one. Therefore, we propose a multi-blockchain system named BASIC, where each cloud provider participates in the maintenance of a consortium blockchain to record information about inter-cloud migrations. Additionally, each cloud provider might choose to keep a local blockchain to secure intra-cloud migrations. Inter-blockchain communication is possible via a node, which has access to both blockchain and functions as a gateway. Results show the impact of different parameters on the system performance, especially the influence of a generic consensus algorithm on the migration delay.

This paper is organized as follows. Section II presents the related work. Section III describes the architecture and the main characteristics of our multi-chain system. In Section IV, we detail our simulation scenario and parameters. In Section V, we present and analyze the simulation results. Section VI presents our conclusion and future work.

II. RELATED WORKS

Most common approaches concentrate on mitigating specific attacks on virtual machines and their components [START_REF] Patil | An exhaustive survey on security concerns and solutions at different components of virtualization[END_REF] and to build trust on VM migration, especially when considering Joint-cloud scenarios [START_REF] Ahmed | Trust evaluation in cross-cloud federation: Survey and requirement analysis[END_REF], [START_REF] Aslam | Security and trust preserving inter-and intra-cloud VM migrations[END_REF]. However, our goal does not focus on protecting nor detecting VM attacks or malfunctioning. Instead, we concentrate our efforts to verify the integrity of a VM when it arrives at the destination server.

In the most similar work, the authors [START_REF] Bozic | Securing virtual machine orchestration with blockchains[END_REF] propose to secure VM migration using blockchain technologies. The authors consider only intra-cloud migration and use a unique blockchain to store every single VM migration procedure, by each physical server. Therefore, our approach differs in two aspects. First, we consider both intra-and inter-cloud migrations, which has led us to propose a multi-chain system. Second, to improve the system performance and, as a consequence, its scalability, we reduce the number of transactions that correspond to a unique migration. In another related work, the authors propose using a blockchain approach to secure the migration of Virtual Network Functions (VNF) [START_REF] Alvarenga | Securing configuration management and migration of virtual network functions using blockchain[END_REF]. Their goal is to store VNF configuration states in transactions, using a single blockchain. However, they do not consider a multicloud scenario.

Some work applies blockchain technology in a Joint-cloud context but does not consider VM migrations nor contemplate the possibility of multiple blockchains. Kai Wang et al. propose using blockchain technology to coordinate the collaborative services of vehicular Joint-cloud [START_REF] Yin | Joint cloud collaboration mechanism between vehicle clouds based on blockchain[END_REF]. In [START_REF] Zheng | Ethershare: Share information in jointcloud environment using blockchain-based smart contracts[END_REF], the authors use smart contracts to store the rights of users in Joint-cloud scenarios.

Several approaches consider multi-blockchain systems, for a variety of applications and thus, the concept of cross-chain communication arises. Hence, different cross-chain communications might exist with distinct complexity [START_REF] Qasse | Inter blockchain communication: A survey[END_REF]. In general, there are three main approaches to cross-chain communications: (i) using an inter-chain protocol that is responsible for exchanging transactions among different chains [START_REF] Borkowski | Cross-blockchain technologies: Review, state of the art, and outlook[END_REF]; (ii) using an intermediate chain combined with smart contracts [START_REF] Jiang | A cross-chain solution to integrating multiple blockchains for IoT data management[END_REF], and (iii) a hybrid approach that considers the two previous ones [START_REF] Borkowski | Cross-blockchain technologies: Review, state of the art, and outlook[END_REF].

In this paper, we propose a hybrid cross-chain approach in which a global blockchain is maintained by a consortium of cloud providers to ensure the integrity of VM inter-cloud migrations. Moreover, an inter-blockchain communication system is proposed by using nodes capable of routing transactions in both blockchains when using a local blockchain.

III. BASICS

In our scenario, several cloud operators need to migrate virtual machines not only inside their clouds, namely a local VM migration, but also across clouds from different cloud operators, namely, an inter migration. However, these virtual machines might suffer from malfunctioning problems, might be compromised due to security attacks, or even be modified along the path to the destination, like in a man-in-the-middle attack. In these cases, it is not recommended to accept such a machine in a new physical server, regardless of the type of migration (local or inter). Therefore, the main goal of this work is twofold: (i) preventing physical servers to accept a VM that was modified by third parties before its arrival; and (ii) providing means of tracking all VM migrations.

We assume that cloud operators are responsible for all migration decisions. Hence, after a migration decision is made, the cloud manager must follow four basic steps: (i) stop the execution of the virtual machine and (ii) generate unique identification (V M ID ), by applying a hash function to the VM content. Next, (iii) the cloud manager sends the VM to its new destination. Finally (iv), it creates a transaction, containing all relevant information about the VM migration, including the V M ID , and sends it to the blockchain. Therefore, upon receiving the VM, the destination can apply a hash function to the content of the VM and then compare it to the V M ID from the transaction associated with this migration, which is already in the blockchain. If the hash matches with the V M ID , the migration has succeeded, otherwise the VM is discarded. This basic procedure prevents the destination server from accepting VMs that have been modified by third parties. In addition, it provides means of tracking the history of VM migrations.

A. System architecture

BASIC is a multi-chain approach in which each cloud operator participates in the maintenance of a consortium blockchain to store information on inter-cloud migration. The consortium blockchain has the advantage of decentralization and therefore, is trustless since cloud operators do not need to trust each other to reach a consensus on the state of the distributed ledger. Moreover, it provides high performance due to the limited and selective group of nodes participating in the blockchain. In addition, each cloud operator might choose to maintain a local blockchain to secure its intra-cloud migrations between the same or distant data centers. Participants of the local blockchain might be nodes operating in each data center of the cloud operator. Thus, the local blockchain is considered to be permissioned. In our case scenario, we have considered that each cloud operator maintains a local blockchain to evaluate the inter-chain communication. It is worth noticing, that the local blockchain and the consortium blockchain are independent and run their own consensus algorithm.

In this architecture, each cloud contains miners for the local blockchain, named local validators, as well as miners for the global chain, named inter validators. Cloud operators decide the amount of local and inter validators. Additionally, each cloud maintains a gateway node that receives the transactions from the cloud manager and is also responsible for the communication between the two blockchains.

B. Migration procedure

BASICS includes 4 types of transactions:

• Indication: this transaction indicates an attempt to migrate a VM to a specific physical server. It must include the V M ID . • Confirmation: the destination server use this transaction to confirm that the VM has been received and the hash matches the one included in the Indication transaction. • Arrival: it indicates that a new VM has been accepted in the cloud. • Leave: it indicates that a VM from this cloud has successfully migrated to another cloud, and thus, no longer belongs to this cloud.

In step three from the basic procedure, after creating the transaction associated with the current migration, the cloud manager sends it to the cloud gateway.

Upon receiving a transaction, the cloud gateway verifies the type of migration and sends an indication transaction to the proper set of validators, local or inter. Validators will mine blocks with a specific number of transactions. When the block is in the blockchain, one of the validators, in each cloud, announces to the cloud gateway all the new committed transactions in the current block that concerns its own cloud. Hence, whenever a new indication transaction is committed, the destination cloud gateway will receive it and send it to the destination cloud manager. Next, the hash verification occurs, and the cloud manager confirms the successful reception of the VM to the cloud gateway. The gateway creates a conf irmation transaction and sends it to all validators, according to the type of migration. Similarly, the source cloud gateway will receive the confirmation, as soon the conf irmation transaction appears in a committed block. Therefore, whenever a cloud gateway receives a conf irmation transaction, it must verify whether it is a local or inter migration. In the first case, the migration has successfully finished, and it is already stored in the local blockchain because the VM has not left its cloud. However, if the conf irmation refers to an inter migration, then it means that the transaction has appeared in the global chain. Thus, the source gateway creates a leave transaction in its local chain, and the destination gateway creates an arrival transaction in its local chain. Hence, the inter migration can be considered finished only when a leave transaction is committed in the local blockchain in the source cloud, as illustrated in Figure 1.

IV. SIMULATIONS

We use NS-3 to perform our simulation. To that, we have developed a blockchain and a generic consensus module that allows us to measure the performances of our cross-blockchain system based on a full-stack TCP/IP network infrastructure. Figure 2 shows the main scenario with three clouds where each cloud has a set of local and inter validators. The number of clouds and the number of validators are a parameter in our simulation. All nodes in a cloud are connected to a switch to simulate realistic cloud throughput, delays, and jitters. Besides, every cloud owns a router that is connected to the Internet.

Fig. 2. Simulation scenario

The Internet is simulated by a single router that is connected via a point-to-point connection to every cloud router. Therefore, local validators are connected by a switch in a local network, while inter validators connect to their peers through a P2P overlay connection that traverses the Internet. Hence, we have two distinct communication delays for each blockchain. The validators implement the Blockchain module that manages the blockchain, while the gateways implement a TransactionApp module that creates and manages transactions.

A. Consensus

Since our multi-chain system supports different types of consensus, we implement a generic consensus that is aware of everything. The main idea consists of simulating different types of consensus with specific characteristics, just by tuning the parameters of the Oracle consensus. Hence, Oracle have three main parameters: sendblockdelay, blockcommitdelay, and the f actor. The block-commit delay corresponds to the time Oracle takes to send the block to all its peers. Therefore, considering a blockchain with np peers, with a block size of bck size , measured in number of transactions, and the average size of transactions tx size , the total delay for sending the block to all peers, considering multiple parallel connections is approximately given by:

delay send = np × (D tr + D pg ) + D qu + D pc (1)
where D tr is the transmission delay, D pg is the propagation delay, D qu is the queuing delay, and D pc is the processing delay. We consider this the delay for committing a block after it was sent to all peers, as the time to process and receive the ACKs. As a simplification, we considered the same value as the time to send the block. As a consequence, we consider the total delay to commit the block is commit delay min = 2 × Delay send. Finally, we assume that this commit delay is the ideal consensus, namely a lower bound to the block-commit delay. To evaluate the impact of different consensus, we include the Oraclef actor (O f ) parameter, which allows us to consider different values for the block-commit delay, according to the minimum delay, explained above. Therefore, the blockcommit delay is given by: bck commit delay = O f × commit delay min , [START_REF] Lee | Cloud federation management and beyond: Requirements, relevant standards, and gaps[END_REF] with O f ≥ 1. Besides, Oracle elects one leader, from the set of validators, responsible for generating the blocks in its blockchain. Table I summarizes the main parameters of our simulator along with their default values used for every simulation run.

V. RESULTS

To evaluate the performance of BASICS we run different sets of simulations and measure four performance metrics:

• VM migration delay: is defined by the time a migration transaction arrives at the gateway until the last transaction associated to this migration appears in one block in the local blockchain. • Block-commit delay: is defined as the time interval between the moment the Blockchain module sends a new block B i to the Oracle consensus and the Blockchain module adds the block B i in the blockchain. This metric is expressed in Equation 2. • Inter-block delay: is defined as the time interval between the inclusion of two consecutive blocks in the blockchain. • Number of blocks: is defined as the number of blocks committed by the consensus and stored in the blockchain. In each set of simulations, we vary different parameters to assess their impact on the system performance. Hence, for each simulation, we define the varying parameters and their respective values as well as specific values for particular parameters. All other parameters not mentioned assume the default values presented in Table I. The simulation time is 200 seconds. All results correspond to the mean of at least ten simulation runs, with a 95% confidence interval, represented by the error bars.

A. System stability

First, it is important to understand that our multi-chain system might present two basic behaviors regarding the migration delay, as shown in Figure 3, which illustrates the inter-migration delay variation over time in a simulation of 60 seconds, for two different migration rates. The blue line, with the lower rate, shows a bounded migration delay, and thus, a stable behaviour. The black line indicates the average delay of the blue line. However, the red line, with a much higher rate, manifests an unstable behavior with an unbounded delay. Therefore, it is crucial to respect the system capacity in terms of the migration rate to avoid unstable behaviours.

B. Oracle consensus performance

We evaluate the performance of Oracle regarding the blockcommit delay. The main idea is to assess the impact of other parameters on the block-commit delay. Figure 4 reveals the influence of the number of inter validators on the blockcommit delay, defined in Eq. 2, varying the oracle factor and the link data rate for the P2P connections. It is interesting to notice that the number of inter validators has no perceptive impact on the block-commit delay with a higher link data rate, even when we multiply by four the minimum commit delay, as shown in Figure 4(a). It is important to remember that we considered the possibility of creating multiple TCP connections. On the other hand, Figure 4(b) shows that, with a lower link data rate, increasing the number of validators augments the block-commit delay. Most important, Figure 4 illustrates how we can parameterize the oracle consensus to simulate different block-commit delays.

C. Local blockchain

To evaluate the local blockchain we isolated it from the global chain by setting the inter-migration rate to zero. Hence, there are only local migrations. First, we analyze the effect of the number of local validators on the migration delay. Figure 5 shows the delay when we vary the number of validators from 4 to 164. In Figure 5(a), we use different values for the blockcommit delay, represented by the Oracle factor. Results show that the variation of the number of validators has no perceptive impact on the migration delay. However, the block-commit delay directly affects the migration delay. In Figure 5(b), we use two different values for the data link rate of the local network. We observe that increasing the number of validators with a lower data link rate has a significant impact on the migration delay. Next, we vary the local migration rate to evaluate the migration delay and the scalability of the local blockchain regarding the number of migrations per second. Figure 6 shows the migration delay with different migration rates, using two block sizes. First, we can observe that the size of the block is an important parameter to define the migration delay, as expected. The larger is the size of the block, the longer the system will take to fill the block, considering a specific migration rate. Therefore, the inter-block interval increases as shown in Figure 6(b). It is important to remember that increasing indefinitely the migration rate is not an option since, at some point, the system reaches its own limit beyond which the stability of the system is compromised. In this specific scenario, the limit is between 128 and 256 migrations per second.

D. Global blockchain

We evaluate the behavior of the global chain regarding the inter-migration delay. Figure 8 shows the results for the intermigration delay when varying the inter-migration rate from 0.25 to 16 migrations per second for two block sizes. We can observe that, similar to the local blockchain, increasing the inter-migration rate allows the leader to complete a block faster, and as a consequence, we can reduce the inter-migration delay significantly. However, for the global chain, the limit on the migration rate is much lower than the local chain, due to the significant difference in the delay for committing a block in both blockchains. The main reason for this discrepancy is the difference in the Round Trip Time (RTT), since local migrations are confined to a local network, while inter migrations must traverse the Internet.

E. Multi-chain system

After understanding the performance of the two blockchains separately, it is important to evaluate the whole multi-chain system. First, we assess the impact of the number of participating clouds on the system performance. To accomplish this goal, we fixed the number of validators and migration rates to their default values and vary the number of clouds from 4 to 20. Figure 9(a) shows that increasing the number of clouds only affects the global chain performance. This is an expected result, since every cloud generates a certain number of local and inter migration. Hence, local migrations are confined to each cloud, and as a consequence, the number of clouds has no effect on the local-migration delay. However, as inter migrations share the same global blockchain, augmenting the number of clouds leads to a rise in the overall migration rate, which reduces the migration delay, as discussed previously. Even though inter migrations also generate transactions in the local blockchains, the increase in the overall inter-migration rate does not affect the performance of local chains because these local transactions are proportionally spread among the participating clouds. Afterward, we set the proportion between local and inter migrations rates to 4:1, in each cloud. Then, we vary the localmigration rate from 1 to 32 for different block-commit delays (Oracle factors). Figures 10 illustrate the results for the global chain with a block size of 4. We can observe the shift in the stability point when the block-commit delay increases. Figure 10(b) indicates when the inter-block delay reaches the minimum block-commit delay that corresponds to the point beyond which the system becomes unstable.

VI. CONCLUSION

In this paper, we propose BASICS, a multi-blockchain system to secure VM migration in Joint-cloud systems. We implement the proposed solution in NS-3 to evaluate the system performance and its scalability. We developed emulate a generic consensus, named Oracle, that emulate consensus with different characteristics. Hence, we evaluate our system in terms of migration delay, inter-block delay, the number of blocks, and the block commit-delay. We assess the influence of several parameters on the performance of our multi-chain systems. Results allow us to characterize and understand the behavior of the system as well as its relations to the main parameters. They also show the stability limitation of our systems and the trade-off between increasing the system capacity and reducing the average migration delay.

Fig. 1 .

 1 Fig. 1. BASICS -Inter-migration procedure

Fig. 3 .

 3 Fig. 3. Multi-chain stability

Fig. 4 .

 4 Fig. 4. Block-commit delay

Fig. 5 .

 5 Fig. 5. The effect of the number of local validators on the migration delay

Fig. 6 .

 6 Fig. 6. Local migration with different migration rates for block sizes of 4 and 16 transactions.

Fig. 7 .

 7 Fig. 7. The effect inter-migration rate on the migration delay with different block sizes Another interesting result is the impact of the intermigration rate on the local blockchain. The blue curves in Figure 8 indicate that increasing the inter-migration rate reduces the local migration delay. Indeed, inter migration also generates local transactions, as explained in Section III-B.Figures8(a) and 8(b) point out the total number of blocks in the local chains and the global chain. Results confirm that using a larger block size implies fewer blocks, as expected. In addition, we observe the effect of the inter migrations generating local transactions in the local chains. Thus, the rise in the number of blocks in the local chain is entirely due to the inter migrations since the number of local migrations does not change.

Fig. 8 .

 8 Fig. 8. The effect inter-migration rate on the number of blocks

Fig. 9 .

 9 Fig.9. The effect of the number of clouds on the performance of our multichain system.

Figure 9 (

 9 Figure 9(b) shows the number of blocks in the local chains and global chain when varying the number of clouds. Results confirm that increasing the number of clouds augments the number of blocks in the global and local blockchains. Besides, the blue curve concerning the local chains presents a higher slope. It occurs because, additionally to the rise of the number of blocks due to the augmentation of the number of clouds, there is the effect of the inter migrations on the local chains, as discussed above.Afterward, we set the proportion between local and inter migrations rates to 4:1, in each cloud. Then, we vary the localmigration rate from 1 to 32 for different block-commit delays (Oracle factors). Figures 10 illustrate the results for the global chain with a block size of 4. We can observe the shift in the stability point when the block-commit delay increases. Figure10(b) indicates when the inter-block delay reaches the minimum block-commit delay that corresponds to the point beyond which the system becomes unstable.

  Fig.10. The effect migration rate on the inter migration delay and inter-block delay, with 4:1 proportion and different Oracle commit delays.