Valérie Issarny
email: valerie.issarny@inria.fr

Ferda Tartanoglu
email: galip-ferda.tartanoglu@inria.fr

Franc ¸oise Sailhan Jinshan Liu
email: jinshan.liu@inria.fr

Software Architecture for Mobile Distributed Computing *

Today's wireless networks and devices support the dynamic composition of mobile distributed systems, according to device connectivity. This has in particular led to the introduction of a number of supporting middleware. However, such solutions need to be complemented with adequate modeling and verification support towards enforcing the correctness of the dynamic mobile systems with respect to both functional and non-functional properties. Building on the elegant properties of software architecture modeling, this paper introduces base modeling of mobile software components, which integrates key features of the wireless infrastructure and allows for reasoning about the behavior of dynamically composed systems.

Introduction

Modeling software architectures is now recognized as a useful approach towards controlling the complexity of software systems, in particular due to the associated support for assessing the software systems' behavior with respect to provided functional and non-functional properties [START_REF] Issarny | Systematic aid for developing middleware architectures[END_REF]. Architectural modeling further enables dealing with the dynamic evolution and adaptation of software systems, providing adequate abstractions to specify changes to the system's configuration and to further reason about the dynamic system's behavior [START_REF] Métayer | Software architecture styles as graph grammars[END_REF][START_REF] Magee | Dynamic structure in software architecture[END_REF][START_REF] Andrade | Architecture-based evolution of software systems[END_REF]. Mobile distributed software systems constitute a typical example of dynamic systems that need to adapt according to the environment. Specifically, mobile systems need to be dynamically configured according to the networked resources that are reachable, which change over time due to the highly dynamic network topology. Such a requirement has led to revisiting traditional architectural styles of distributed systems so as to deal with the network's dynamics and resource constraints of the mobile, wireless devices. In the most general case, the mobile distributed system is dynamically composed out of the networked resources, which may be driven by adequate architecture modeling [START_REF] Sousa | Aura: an architectural framework for user mobility in ubiquitous computing environments[END_REF][START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF]. However, such a modeling must not only support the dynamic integration and composition of the networked resources, it must also allow enforcing correctness of the mobile distributed systems with respect to functional and non-functional properties.

This paper addresses base architectural modeling for mobile distributed computing, towards enforcing systems correctness. We first provide an overview of mobile distributed systems, discussing their key features ( § 2), from which we derive base architectural style, i.e., architectural modeling so as to support dynamic integration and composition of networked resources for adaptive configuration of mobile distributed software systems ( § 3). We then concentrate on assessing dynamic systems using our model, which is further illustrated in the context of mobile e-services ( § 4). The actual dynamic composition of mobile distributed systems is tightly coupled with the supporting run-time environment (i.e., middleware), leading to the investigation of the integration of our architectural modeling with the WSAMI middleware based on the Web services architecture, which we introduced for distributed mobile computing ( § 5). Finally, we conclude by a summary of our contribution and our current and future work ( § 6).

Mobile Distributed Systems

Mobile distributed systems cover a broad spectrum of software systems, by considering all the forms of mobility, i.e., personal, computer, and computational [START_REF] Roman | Software engineering for mobility: A roadmap[END_REF]. In this paper, we focus on the mobility of devices, as enabled by today's wireless devices. Then, most specifics of mobile distributed systems compared to their stationary counterpart follow from the features of the wireless infrastructure ( § 2.1). Mobile software systems must in particular cope with the network's dynamics ( § 2.2) and quality of service management, as the mobile environment makes it particu-larly challenging due to resource constraints of the wireless devices and varying bandwidth ( § 2.3).

Wireless infrastructure

The wireless infrastructure is primarily characterized by the heterogeneity of networks and devices.

Today's wireless networks may be subdivided into two categories: (i) infrastructure-based and (ii) ad hoc [START_REF] Ritter | Mobility network systems[END_REF]. With the former, base stations handle traffic to/from mobile terminals in their transmission range, using either licensed (e.g., GSM, GPRS, UMTS) or unlicensed frequency bands (e.g., IEEE 802.11 Wireless Local Area Network). With the latter, wireless nodes form a dynamic and temporary network according to their respective location, using unlicensed frequency bands (e.g., IEEE 802.11 in the ad hoc mode, Bluetooth Personal Area Network), and may further act as routers in the context of Mobile Ad hoc NETworks [START_REF] Broch | A performance comparison of multi-hop wireless ad hoc network routing protocols[END_REF]. Hybrid networks then integrate the various wired and wireless technologies, actually leading to the mobile Internet.

The diversity of wireless devices keeps evolving and embodies devices from the ICT (e.g., PDAs, cell phones, wireless storage devices) and Consumer Electronics domains (e.g., TV, MP3 players, gaming devices, cameras), with most of them featuring a combination of wireless connectivities (e.g., PDAs equipped with GSM, WLAN and WPAN). Specialized devices are also being offered such as sensors/beacons, smartcards.

The above allows deployment of mobile distributed systems that provide mobile users with seamless access to a rich set of services and content. However, the wireless infrastructure poses specific challenges on the software systems compared to the wired environment. In particular, the dynamics of the network calls for dedicated support, as discussed in the next section.

Dynamic networking

Initial work on the management of the network's dynamics has focused on handling mobility-induced failures that result from the occurrence of network disconnections, which has led to significant research effort since the emergence of wireless infrastructures in the early 90s. The basic technique to handle such failures is optimistic replication, i.e., the content (and related service) is replicated on the wireless devices so as to allow continuing access when disconnected, and is later synchronized with peer copies according to network connectivity (e.g., see [START_REF] Terry | Managing update conflicts in a weakly connected replicated storage system[END_REF]). The hybrid network further allows for replication at various levels, from the wireless device to some area network, on either trusted or untrusted node, which may be wireless or stationary [START_REF] Sailhan | Cooperative caching in ad hoc networks[END_REF]. However, optimistic replication impacts upon the behavior of the system, which is dependent upon the specific replica that is accessed and cannot be made transparent to the application.

A more general approach to the management of the network's dynamics, following advances in wireless networks, lies in the automatic configuration and reconfiguration of networked devices and services. This is in particular supported by resource discovery protocols that provide proactive mechanisms for dynamically discovering, selecting and accessing reachable resources that meet a given specification [START_REF] Bettstetter | A comparison of service discovery protocols and implementation of the service location protocol[END_REF]. This leads to building event-based systems, as (wireless) nodes advertise and consume networked resources according to their specific situation and requirements. This further leads to the design of mobile distributed systems as systems of systems, whose component systems are autonomous and hosted by networked nodes, either wireless or stationary. The systems' configuration then evolves and adapts according to the network connectivity of component systems. Specific solutions differ according to the way they deal with the integration of components, which is closely related to the system's interaction paradigm. Two approaches can be identified:

• Data-oriented systems that integrate component systems at the level of the underlying data repository, where the repositories of the networked nodes are dynamically and virtually coupled according to network connectivity of the nodes, as, e.g., in the LIME system [START_REF] Picco | Developing mobile computing applications with LIME[END_REF]. • Service-oriented systems that integrate component systems through the dynamic binding of clients with services in a peer-to-peer way according to network connectivity of clients, as, e.g., in the WSAMI system [START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF].

Note that replication management to handle mobilityinduced failures may be considered as a special case of the dynamic integration of component systems; replicas are component systems that in particular synchronize when connectivity allows.

Independent of the composition approach, the autonomous systems that get composed are in general loosely coupled due to the network's dynamics. However, the composition shall ensure the correctness of the system's behavior with respect to target functional and non-functional properties. With respect to the former, the composition must enforce selection of the appropriate component systems and coordination protocols that conform to the specification of the component systems. With respect to the latter, it is mandatory to account for the quality of service delivered by component systems and their integration.

Quality of service

The features of the wireless network make the management of Quality of Service (QoS) mandatory for mobile distributed systems. Specifically, the dynamic composition of mobile distributed systems must both minimize resource consumption on mobile nodes and satisfy the users' requirements with respect to perceived QoS. The resource limitation of wireless computing devices makes QoS-aware resource management even more important. QoS specification associated with component systems is then concerned with capturing the systems' QoS requirements and policies.

QoS specification should: (i) allow description of both quantitative (e.g., service latency) and qualitative (e.g., CPU scheduling mechanism) QoS attributes, as well as adaptation rules [START_REF] Sabata | Taxonomy for QoS specification[END_REF]; (ii) be declarative in nature, that is, specify only what is required, but not how the requirements are implemented [START_REF] Aurrecoechea | A survey of QoS architectures[END_REF]. In addition, although more QoS parameters yield more detailed description, the gain has to be put against the increased overhead. Usually, dominant QoS properties of systems may be captured with a small number of attributes [START_REF] Dijk | ARC: A bottom-up approach to negotiated QoS[END_REF]. We identify the following key QoS attributes for the mobile system [START_REF] Liu | QoS-aware service location in mobile ad hoc networks[END_REF]: (i) performance, (ii) reliability, (iii) security, and (iv) transactional properties. This is further complemented with related resource consumption (i.e., CPU load, memory, bandwidth, battery) and service adaptation.

Base Architectural Style

As discussed in the previous section, mobile distributed systems now tend to be built out of the composition of mobile, autonomous component systems. This may be conveniently modeled at the software architecture level: components abstract mobile component systems ( § 3.1) and connectors abstract interaction protocols above the wireless network ( § 3.2).

Architectural modeling must comprehensively address the key characteristics of mobile distributed systems, i.e., dynamic composition, in a way that ensures correctness of the system. The following introduces a base architectural style that models key aspects of mobile distributed systems. Our model is grounded in the service-oriented interaction paradigm, i.e., a component abstracts a networked service that invokes operations of peer components and dually executes operations that are invoked. However, it applies as well to interactions based on data sharing, since the distinction is apparent at the implementation level only.

Mobile components

As in traditional software architecture modeling, a system component specifies the operations that it provides to and requires from the environment. The dynamic composition of the mobile component with components of the environment further requires: (i) enriching the component's functional specification so as to ensure adherence to the coordination protocols to be satisfied for ensuring correct service delivery despite the dynamics of the networks, i.e., the interaction protocols that must be atomic, and (ii) specifying the component's non-functional behavior so as to enforce quality of service. In the following, we denote keywords using the type writer font, and zero or more occurrences of n by {n} * .

Functional specification. The specification of coordination protocols among mobile components relates to the one of conversation, also known as choreography, in the context of Web services 1 . Such a specification also relates to the one of interaction protocols associated with component ports to ensure conformance with connector roles, as, e.g., supported by the Wright language [START_REF] Allen | A formal basis for architectural connection[END_REF]. Hence, from the standpoint of component's functional behavior, a mobile component is modeled as: In the above, an operation is abstracted by its signature, which provides the operation's name and the type of associated input and output content. Conversations are specified as processes in the π calculus [START_REF] Milner | Communicating and Mobile Systems: The π-Calculus[END_REF], where we use the following notation:

P, Q ::= Processes P |Q Parallel composition P + Q Choice !P Replication v(x) Input communication v(x)
Output communication 0

Null process

We recall that the input process v(x).P is ready to input from channel v, then to run P with the formal parameter x replaced by the actual message, while the output process v(y).P is ready to output message y on channel v, then to run P . The reduction relation, noted →, is further defined over processes, with P → P 1 expressing that P can evolve to process P 1 as a result of an action within P . For instance, we have:

((v(x).P + P )|(v(y).Q + Q )) → P |Q{ x / y }, with Q{ x / y } meaning that x replaces y in Q.
Specifically, an input conversation is modeled as a process P with the communications in P being restricted to input communications over provided (input) operations and to output communications over required (output) operations of the mobile component, given that the process starts with an input communication. In addition, communication actions abstract the interaction protocol provided by the presentation layer, i.e., the middleware whose behavior is modeled at the connector level (see § 3.2). This is because, here, we are concerned with modeling the interactions handled by application-related components. For instance, assume a mobile component that is built on top of a middleware supporting RPC-based interactions, i.e., synchronous, two-way interactions. Further assume that the component offers the operation browse(x) that returns the set of goods matching the criterion x. An input communication (e.g., browse(x)) then abstracts the handling of operation invocation at the callee, i.e., reception of the request message followed by the emission of the corresponding result message. Dually, an output communication (e.g., browse(x)) abstracts operation invocation at the caller, i.e., emission of the request message followed by the reception of the corresponding result message.

An input conversation then characterizes the set of operations that need to be invoked on the software component by caller for the former to deliver a correct service, as specified by the input communications stated in the corresponding process. In the specific case where P amounts to a single input communication (e.g., op(x)), this means that the named operation (e.g., op) is self-contained. As an illustration, consider an e-commerce service that allows browsing a catalogue (with operation browse) and buying goods (with operation buy) after the customer logs in (with operation login) until the consumer logs out (with operation logout). The corresponding input conversation of the eservice is modeled as: login(id).(!(browse(x) + buy(y))) + logout(s)). An input conversation may additionally specify the output communications on which depend the realization of the conversation, i.e., related component integration/composition that is required for correct service provisioning. Such a specification is not mandatory. However, it may be conveniently exploited by the run-time system for anticipating interactions and thus realizing related dynamic bindings before the actual invocations, which is known as prefetching.

Similarly, an output conversation is specified as a process P , with communications in P being restricted to output communications over the component's output operations. The process P specifies the set of interactions that must take place between the caller and the peer components with which it integrates. Still considering our previous example, an output conversation that conforms to the above provided input conversation is: login(id).(!browse(x)+logout(s)), assuming a customer that only browses the service catalogue.

A number of consistency checks may then be performed over the specification of a mobile component. In particu-lar, any input conversation that specifies output communications should conform with the component's output conversations associated with related operations. Such a conformance checking lies in verifying observational equivalences between processes, restricted to output communications.

Non-functional specification. As discussed in Section 2.3, the minimal set of QoS attributes for mobile components relates to specifying the component's behavior with respect to performance, reliability, security, and transactional properties, which is further complemented with related resource consumption and service adaptation [START_REF] Liu | QoS-aware service location in mobile ad hoc networks[END_REF].

Performance and reliability properties are both quantitative. They are respectively specified with the service latency (i.e., response time) and the probability of service availability, for individual operations. From the perspective of the caller, the values of both attributes are further impacted by the available network bandwidth and related mobility of the involved hosts. Security and transactional properties are both qualitative. The former specifies the security protocol on which the mobile component relies for secure communication; it thus relates to the behavior of connectors (see § 3.2). The latter specifies the transactional properties that hold over individual operations and conversations. Resource consumption is further specified quantitatively, stating for each operation, the percentage of resource that is consumed relative to overall resource availability at the host. Finally, service adaptation specifies scaling actions that can be undertaken to accommodate resource constraints.

We get the following modeling for non-functional properties, as highlighted in bold face: The quantitative QoS attributes (i.e., performance, reliability, resource) provide mean values at the provider, given that they are assumed to be regularly updated. Scaling actions are specified with respect to the content type that is exchanged, providing a sequence of message types ordered according to decreasing level of quality of service with respect to the accuracy of the content (e.g., for an image type, we may have <colour, black&white, text >).

The transactional attribute associated with a conversation is a real value d, which equals 0 if the conversation is non-transactional, and is greater than 0 otherwise. The latter case specifies that under the occurrence of a disconnection that lasts longer than d seconds, during the execution of the conversation, the conversation's effect will be undone by the provider(s) according to the atomicity property of transactions.

Wireless connectors

In the mobile environment, connectors specify the interaction protocols that are implemented over the wireless network. In addition, the dynamic composition of mobile components leads to the dynamic instantiation of connectors. Hence, the specification of wireless connectors is integrated with the one of mobile components (actually specifying the behavior of connector roles), given that the connectors associated with two interacting mobile components must compose. The specification of any mobile component is then extended with the one of connector types, as follows: Connectors specifies the set of connector types via which the mobile component communicates, and connector specifies for every conversation, the type of the connector that is used for the corresponding interactions. More precisely, a wireless connector specifies: (i) the base interaction protocol with peer components (protocol), and (ii) the underlying dynamic network (network).

Interaction protocol. Interaction protocols are specified as processes in the π calculus. However, it should be noted that this characterizes message exchanges at the transport level to realize the higher-level protocol offered by the middleware on top of which the mobile component executes.

Dynamic networking. Specification of the underlying network together with its dynamics abstracts the discovery process that is inherent to today's mobile distributed systems.

Such a characterization is further needed due to the diversity of discovery protocols (e.g., wide-area, location-based in the local area and/or with respect to geographic positioning, centralized versus decentralized) together with the one of wireless networks. The dynamic network is then modeled as:

Network:

(Dynamics: boolean) (Area: [Local | Internet]) (Location:
area restriction) (Security:

protocol)

The Dynamics attribute specifies whether the peer mobile components accessed via the connector should be dynamically retrieved or not. In the latter case, the addresses of the components are provided as parameters of the connector. The Area attribute characterizes whether the peer mobile components should be sought within the local or the wide area (i.e., Internet). The Location attribute, which is optional, further specifies the area within which the components are to be retrieved, which may be a given domain identified by its IP address, or a location-dependant domain that is characterized by a geographical area and/or a number of hops, i.e.:

Location:

(Domain: list of domains' IP addresses) (Region: geographical coordinates of reference, max distance) (AdHoc:

Number of hops)

The Security attribute specifies the security protocol that is implemented for any interaction with components over the wireless connector. The protocol is specified using the π calculus, as introduced in [START_REF] Abadi | Mobile values, new names, and secure communication[END_REF] and further elaborated in [START_REF] Bhargavan | A semantics for web services authentication[END_REF].

Note that in the open, mobile environment, traditional security tokens based on public-key signatures may be too restrictive for the interacting mobile nodes. Instead, interactions may be undertaken on the basis of the mobile components' reputation, and related security protocols [START_REF] Liu | Enhanced reputation mechanism for mobile ad hoc networks[END_REF].

Quality of service. The system's QoS may be solely dependent upon the QoS properties of the interacting components and the underlying network. However, connector customization towards enforcing QoS has been recognized as a key technique since the emergence of mobile clients. Such a customization is realized by specialized networked components, which may be hosted either by stationary servers tightly coupled with the network's infrastructure in the context of infrastructure-based networks [START_REF] Fox | Adapting to network and client variation using active proxies: Lessons and perspectives[END_REF], or hosted by (possibly mobile) nodes on the network's path [START_REF] Fu | CANS: composable, adaptive network services infrastructure[END_REF][START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF].

Connector customization is very much dependent upon the non-functional behavior of the interacting components since it aims at adapting the interaction so that the respective provided and requested QoSs match. Hence, customization should be implicit, and inferred from the respective behavior of interacting components and properties of the underlying network. This requires the specification of customization processes so as to be able to dynamically integrate them. Based on our previous work [START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF], this leads us to introduce customizer mobile components that filter exhanged messages. The specification of a customizer is then similar to that of a mobile component ( § 3.1).

Dynamic Composition

Given the above specification of mobile components and related wireless connectors, integration and composition of mobile components in a way that ensures correctness of the mobile distributed system may be addressed in terms of conformance of respective functional and non-functional specifications.

Specification conformance

We use the following notation to characterize the specification of a component M : Consider two mobile components: where ∀, ∃, →, ∧ denote classical logical operators for quantification, implication and conjunction; and: -The connectors implement compatible interaction protocols. Specifically, the parallel execution of the corresponding processes reduces to the null process, i.e., (I c |I p ) → * ∼ 0 -The respective dynamic networks of the components intersect. Specifically, when omitting keywords, for: we have:

I Input/
M1 =< I1, O1, CI 1 , CO 1 , IQoS 1 , OQoS 1 , CI t 1 , CO t 1 , C1, B1 > M2 =< I2, O2, CI 2 , CO 2 , IQoS 2 , OQoS 2 , CI t 2 , CO t 2 ,
• init(conv p ,
(domp IP domc = ∅)∧ (regionp space regionc = ∅)∧ (adhocp adhoc adhocc = ∅)
where IP,space,adhoc define intersection on the respective value domains. -The connectors implement compatible security protocols. Specifically, the parallel execution of the corresponding processes reduces to the null process, i.e., (sec c |sec p ) → * ∼ 0).

Customization

Two mobile components may further be dynamically composed through connector customization, which adapts the components' behaviors so that they conform. We say that a customizer composes with a pair of interacting components if the interaction protocol implemented by its connectors for processing input messages (resp. output messages) is compatible with the ones implemented by the relevant connectors of the components, where compatibility of protocols is defined as above, i.e., in terms of reduction to the null process. We then weaken the above conformance relation as follows to support connector customization:

• The types of exchanged messages are not required to match, provided that there exists a customizer that composes and adapts the exchanged content in a way that the content type conforms to the one expected by the interacting components. • The QoS of an input operation is not required to be at least the one of the output operation with which it binds; provided that there exists a customizer that composes and delivers the expected QoS.

Example

In order to illustrate the exploitation of our model, we consider access to a shopping e-service, for which there exist mobile replicated instances, noted me, on the sellers' wireless devices and a stationary instance, noted se, hosted by some server. Access to se and me is allowed for any authenticated client over the wireless Internet.

For simplicity, we focus on the interactions between the mobile and stationary service instances, and consider a subset of relevant operations, i.e., the service offers two transactional conversations that respectively allows browsing a catalogue and buying goods. Both conversations are carried out over an RPC-like connector with reception of the request message followed by the emission of the request result. The wireless connector implements a security protocol based on certificates, specified as:

CP ≡ (authenticate().srv(certif icate). shared(sk).login(encryptedId sk ))

Informally, the client requests the service provider to authenticate itself by issuing the authenticate message. This leads the service provider to send back its certificate (srv(certif icate)), and then the client to send the shared secret key sk that it computed (shared(sk)) followed by its login that is encrypted using the shared key (login(encryptedId sk )). We further assume the dual security protocol CP at the client, i.e.:

CP ≡ (authenticate().srv(certif icate). shared(sk).login(encryptedId sk ))

All the operations of se are further considered to be transactional and to provide very high performance and availability guarantees (denoted by ∞) with negligible resource consumption (denoted by ); this leads se to not support content scaling. We use optimal as a shorthand notation to specify that an operation offers maximal QoS guarantees (i.e., we have (QoS: (performance: ∞) (reliability: ∞) (transactional: true) (resources: , , , ) (scaling: ∅))). Finally, there is no restriction on the location area, leading us to omit the optional Location attribute. We get the following specification for the stationary service se, for which we do not detail content types:

Mobile component se Connectors service: (req(x).res(y)) (Network:
(Dynamics: true) (Area: Internet) (Security: CP process, as specified above) Provides:

browse: (x) (QoS: optimal) book: (y) (QoS: optimal) buy: (z) (QoS: optimal) Requires: ∅ Coordinates:

Input conversation: BROWSE: (browse(x)) (0) (service) BUY: (book(x).(!book(x) + buy(y))) (60) (service) Output conversation: ∅ The specification of me is similar to the one of se regarding the definition of input operations and conversations, since the functional behavior that it offers to its clients is equivalent to that of se. On the other hand, its nonfunctional behavior changes due to its mobile nature, and me further synchronizes with the stationary server when connection allows by forwarding the requests that it has logged. In addition, the conversations with the stationary server do not specify any QoS requirements and are carried out over a connector that restricts the service provider to be se, which is passed as parameter. We get: From the above, it is quite trivial to show that se conforms to me according to the definition provided in Section 4.1. Hence, they can be dynamically composed, while ensuring correct system behavior with respect to provided functional and non-functional properties. However, this needs to be realized online and hence requires adequate middleware support.

Supporting Middleware

We have introduced base architectural modeling for mobile distributed systems, which enforces correctness of the distributed systems despite the high dynamics of the underlying network. However, related verification of the dynam-ically composed systems must be integrated with the runtime system, i.e., the middleware. The issue that arises then relates to the processing and communication costs associated with verification, which must be kept low on the wireless devices.

As part of our work, we have developed the WSAMI service-oriented middleware for mobile computing that is based on the Web services architecture [START_REF] Issarny | Developing ambient intelligence systems: A solution based on web services[END_REF]. Briefly stated, the WSAMI core middleware subdivides into: (i) the WSAMI SOAP-based core broker, including the CSOAP SOAP container for wireless, resource-constrained devices, and (ii) the Naming & Discovery (ND) service for the dynamic discovery of (possibly mobile) services that are available in the local and wide area, according to network connectivity and available resources. The ND service further includes support for connector customization, so as to enforce quality of service through the dynamic integration of middleware-related services over the network's path. The WSAMI middleware has been designed so as to minimize resource consumption on the wireless devices. In particular, mobile services that are integrated and composed using WSAMI are modeled by specifying the URIs of the XML documents that characterise their input and output operations, and their input and output conversations.

Using WSAMI, components composition with respect to QoS and wireless connectors is built-in in the middleware, i.e., QoS-awareness is managed by the ND service and the interaction protocol is that of CSOAP. It follows that the retrieval of peer components with which a mobile service dynamically composes is simply based on the comparison of URIs 2 , which is much effective in terms of low resource consumption. However, such an approach leads to a much stronger conformance relation for dynamic composition than the one discussed in the previous section, i.e., the conformance relation that is implemented in WSAMI requires two interacting components to have structural equivalence over output and input operations, and over output and input conversations. As part of our current work, we are investigating weaker conformance relations for WSAMI based on our general definition, while still making the associated computation and communication costs low for wireless devices. A number of techniques need to be combined in this context, including effective tool for checking conformance relationship in the wireless environment, possibly leading to strengthening base conformance relation, and exploiting the capabilities of resource-rich devices in the area so as to effectively distribute the load associated with the dynamic composition of mobile components. WSAMI further restricts the systems' openness in that it supports the dynamic composition of WSAMI-enabled components. Such a feature is inherent to middleware-based systems. However, high-level modeling of mobile components for composition, as addressed in this paper, paves the way for semantic-based integration and composition of mobile systems. Specifically, the behavioral specification of components may be exploited towards adapting the nonfunctional behavior of the mobile components so that they can integrate, regarding both offered QoS and interaction protocols. Such a concern is in particular exemplified by our approach to connector customization. It further relates to work undertaken within the Semantic Web for better reasoning about the Web content 3 . However, such a capability can only be supported if provided with effective tools for conformance checking and techniques for adapting the interaction protocols of components. Base approaches can be found in the literature to address the latter, introducing automated solutions to, e.g., dynamically change the discovery protocols [START_REF] Grace | Middleware awareness in mobile computing[END_REF] and to adapt to protocol evolution [START_REF] Ryan | Using Event-based Parsing to Support Dynamic Protocol Evolution[END_REF].

Conclusion

Supporting the development of applications for the wireless environment has led to tremendous research effort over the last ten years. In particular, much work is devoted to performance-related issues, investigating middleware solutions to deal with the key features of the wireless infrastructure, i.e., dynamics of the network and resource constraints of the wireless devices. Mobility has also deserved much attention from a more theoretical perspective, with primary focus on the mobility of computation (i.e., mobile code), as opposed to personal and computer mobility. In the context of computer mobility, distributed systems now tend to be dynamically composed according to the networking of mobile services, which is in particular supported by the integration of resource discovery protocols within the middleware ( § 2). However, such a composition must be addressed in a way that enforces correctness of the dynamic composite systems with respect to both functional and non-functional properties. Towards that goal and building upon the elegant properties of software architecture, this paper has introduced a base approach to the modeling of mobile software components (services) hosted by wireless hosts and of related wireless connectors. The proposed solution integrates key features of today's wireless infrastructure, in particular dealing with the network's dynamics and quality of service requirements that call for special care due to inherent resource limitation ( § 3). We have further introduced a conformance relation over component and connector models so as to be able to reason about the correctness of the 3 http://www.w3.org/2001/sw composition of peer mobile components with respect to offered functional and non-functional properties ( § 4). Related verification needs to be carried out online and hence integrated within the middleware, possibly leading to stronger conformance relation to make the associated resource consumption acceptable for wireless devices ( § 5).

By undertaking an approach based on software architecture modeling, our work builds upon work in the area and in particular on the modeling of interaction protocols associated with connectors [START_REF] Allen | A formal basis for architectural connection[END_REF]. We more specifically use the π calculus as the base process algebra, which allows dealing with dynamic architectures [START_REF] Magee | Dynamic structure in software architecture[END_REF]. In addition to the specification of the base interaction protocol that abstracts the behavior of the middleware with respect to communication, we introduce the specification of coordination (also referred to as conversation and choreography) and security protocols within components. The former is mandatory to reason about the functional composition of components and further about the impact of disconnection. The latter relates to one of the key QoS attributes in the wireless context. Our approach to the specification of coordination protocols relates to the definition of XML languages for specifying choreography associated with Web services 4 , since it is quite direct to translate corresponding π processes in a choreography language and conversely. In this context, our modeling of components resembles work on the definition of a formal ontology framework for Web services to support the description, matching and composition through logic reasoning techniques [START_REF] Pahl | Ontology support for Web service processes[END_REF]. Our contribution specifically relates to dealing with mobile components (which may be instantiated as mobile Web services), leading us to integrate the specifics of the wireless environment in the component modeling.

Architecture-based development of mobile distributed systems is in particular addressed by the AURA project [START_REF] Sousa | Aura: an architectural framework for user mobility in ubiquitous computing environments[END_REF]. Briefly stated, a user-task is modeled as a software architecture description that specifies the abstract applicationrelated services and connectors to be composed, and the environment instantiates and adapts the architecture according to available component instances and resources. Architecture modeling in AURA is specifically targeted at the AURA middleware, providing input to the built-in discovery and composition process. Our work is thus complementary, addressing formal modeling towards reasoning about the correctness of composite mobile systems with respect to functional and non-functional behavior, and further addressing key characteristics of the wireless infrastructure.

As discussed in Section 5, openness of the composition process with respect to the mobile components that can actually be integrated is dependent upon the underlying middleware. Considering existing middleware (e.g., AURA and WSAMI), a direct approach is to strengthen the conformance relation over mobile components, which in particular allows minimizing resource consumption induced by the composition process. However, this impacts upon the degree of pervasiveness of mobile computing. We are thus currently investigating base online tools and techniques to support open, dynamic system composition according to the conformance relation introduced in this paper, while keeping the runtime overhead acceptable for wireless, resourceconstrained devices.

  Mobile component nameProvides: {operation name: (signature)} * Requires: {operation name: (signature)} * Coordinates: Input conversation: {conversation name: (process)} * Output conversation: {conversation name: (process)} *

  C2, B2 > Then, M 1 and M 2 may be composed if the conversations that bind according to respective input and output operations, conform to each other, i.e., if the following Conf orm(M p , M c ) (where p stands for provider and c for client) relation holds for (p, c) = (1, 2) (i.e., M 1 being the service provider) and (p, c) = (2, 1) (i.e., M 1 being the service client): Conform(Mp, Mc) ≡ ((∀(convp = P ) ∈ CI p ) : (init(convp, out) ∧ (out ∈ Oc)) ⇒ ∃(convc ∈ CO c )| convc → convp∧ t(convc) ≤ t(convp)∧ QoSconv c ≤qos QoSconv p ∧ connector(convc) ∼co connector(convp))

  netp = (dynp, (areap, domp, regionp, adhocp), secp), netc = (dync, (areac, domc, regionc, adhocc), secc),

  out) holds if conv p starts by executing the out operation. • conv c → conv p holds if the ouput conversation conv c conforms to the input conversation conv p for all the calls to M p 's input operations. Specifically, the parallel execution of the two processes when restricted to interactions with M p 's input operations (noted conv c and conv p ) reduces to the null process (i.e., (conv c |conv p ) → * ∼ 0 with → * denoting a series of reduction and ∼ denoting observational equivalence) and the types of the exchanged messages match in the classical sense of type checking. • t(conv c ) ≤ t(conv p ) holds if the transactional behavior of conv c is weaker than that of conv p (i.e., conv c is transactional if conv p is and the timeout of conv c is smaller). • QoS convc ≤ qos QoS convp holds if the QoS provided by the callee is at least the one expected by the caller for all the input operations of M

p that belong to conv p . Specifically, the quantitative performance (resp. reliability) attributes of the provider must be smaller (resp. greater) or equal to the values requested by the client, the operation must be transactional if it is requested to be so, and the client and provider must agree on similar scaling actions, i.e.: ∀in ∈ convp|qosp(in) = (pp, ap, tp, rp, sp) : in ∈ convc ∧ qosc(in) = (pc, ac, tc, rc, sc)∧ (pc ≥ pp) ∧ (ac ≤ ap) ∧ (tc ⇒ tp) ∧ scalable(sc, sp)

where the scalable(s, s ) relation holds if for any type in s, there is a matching type in s . • connector(conv c ) ∼ co connector(conv p ) holds if the connectors associated with the respective conversations compose, i.e., the following conditions are met for connector(conv p ) = (I p , net p ) and connector(conv c ) = (I c , net c ):

Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04) 0-7695-2172-X/04 $ 20.00 © 2004 IEEE

http://www.w3.org/2002/ws/chor Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04) 0-7695-2172-X/04 $

20.00 © 2004 IEEE

Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04)

Note that this leads to model output conversations from the standpoint of the callee at the caller so that input and output conversations are structurally equivalent.Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04) 0-7695-2172-X/04 $ 20.00 © 2004 IEEE

http://www.w3.org/2002/ws/chor Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA'04) 0-7695-2172-X/04 $ 20.00 © 2004 IEEE

* This work has received the support of the European Commission through the IST programme, in the context of the Ozone project (http://www.extra.research.philips.com/euprojects/ozone/).


Nikolaos-Foivos Polychronou

Pierre-Henri Thevenon

Maxime Puys

Vincent Beroulle

A Hybrid Solution for Constrained Devices to Detect Microarchitectural Attacks

Keywords: IoT, Security, HPCs, Edge-Computing, Local-Remote Detection, Microarchitectural Attacks

We are seeing an increase in cybersecurity attacks on resource-constrained systems such as the Internet of Things (IoT) and Industrial IoT (I-IoT) devices. Recently, a new category of attacks has emerged called microarchitectural attacks. It targets hardware units of the system such as the processor or memory and is often complicated if not impossible to remediate since it imposes modifying the hardware. In default of remediation, some solutions propose to detect these attacks. Yet, most of them are not suitable for embedded systems since they are based on complex machine learning algorithms.

In this paper, we propose an edge-computing security solution for attack detection that uses a local-remote machine learning implementation to find an equilibrium between accuracy and decision-making latency while addressing the memory, performance, and communication bandwidth constraints of resource-constrained systems. We demonstrate effectiveness in the detection of multiple microarchitectural attacks such as Rowhammer or cache attacks on an embedded device with an accuracy of 98.75% and a FPR near 0%. To limit the overhead on the communication bus, the proposed solution allows to locally classify as trusted 99% of the samples during normal operation and thus filtering them out.

Introduction

In recent years, we have observed an increasing number of Internet of Things (IoT) and Industrial IoT (I-IoT) devices. Millions of these devices are placed in critical locations and collect data that are later processed to make appropriate decisions and take actions. However, despite their use in critical applications (such as health, transport or smart cities), IoT devices often lack security guarantees and security support.

In parallel to malware such as cryptolockers, worms or Trojans, a new class of attacks has emerged that we refer to as microarchitectural attacks. Microarchitectural attacks include attacks such as Cache Side-Channel Attacks (CacheSCA) [START_REF] Gruss | Flush+ flush: a fast and stealthy cache attack[END_REF], Rowhammer [START_REF] Gruss | Rowhammer. js: A remote software-induced fault attack in javascript[END_REF], Spectre [START_REF] Kocher | Spectre attacks: Exploiting speculative execution[END_REF], and Meltdown [START_REF] Lipp | Meltdown: Reading kernel memory from user space[END_REF] and target hardware units such as the processor or the memory. One major threat of these attacks is the complexity required to remediate them that often imposes the modification of the component itself or an important overhead on the performances. Thus, in default of remediation, some solutions based on the detection of these attacks were presented in the state of the art to circumvent this problem. Yet, most of them are not suitable for embedded systems. These solutions are based on a complex machine learning algorithm that does not fit in a little processor or solutions that create a huge overhead on the communication bus. In such systems, performance, memory, energy consumption, and communication bandwidth play an important role in adopting a security solution to detect microarchitectural attacks.

Since microarchitectural attacks directly exploit hardware, some works [START_REF] Gulmezoglu | Fortuneteller: Predicting microarchitectural attacks via unsupervised deep learning[END_REF], [START_REF] Mushtaq | Whisper: A tool for run-time detection of side-channel attacks[END_REF], [START_REF] Wang | Hardware performance counter-based malware identification and detection with adaptive compressive sensing[END_REF], [START_REF] Polychronou | Madman: Detection of software attacks targeting hardware vulnerabilities[END_REF] rely on Hardware Performance Counters (HPCs) to detect these attacks. HPCs are special core registers found in most modern processors. They enable the measurement of hardwarespecific events with near-zero overhead for the CPU. Proposed detection solutions extract and analyze HPCs to characterize the behavior of a program using machine learning (ML). Despite the large number of published security solutions using the HPC-ML configuration, most of them are not suitable for IoT devices due to their high overhead induced by complex ML algorithms.

While we aim for a high attack detection rate, we also need to consider a minimum False Positive Rate (FPR, that is, avoiding false alarms during normal execution of the system). Due to the criticality of some IoT systems (health, industry, transport, etc.), they will implement response mechanisms to prevent damage to human or environment. Thus, undetected attacks may damage the system or extract sensitive data. However, frequently triggering response mechanisms due to a false alarm (such as a system recovery) would result in the device not operating properly. Though, a high FPR can also increase system overheads. Furthermore, as IoT devices often extract and transmit data to a remote server, the required bandwidth is a critical parameter for their normal operation.

Related works:

In the literature we find two main implementation approaches: local and remote. The first approach implements the security mechanism locally within devices, either in software or hardware. This approach allows fast detection and reduces communication and memory overhead of storing and transmitting the HPC measurements remotely later. On the downside, this approach increases the performance overhead since we must extract system information and deploy the ML to decide for the presence or not of an attack. Simple ML models such as Logistic Regression (LR), Decision Trees (DT) etc., can reduce the induced overheads. However, due to their simplicity, they have limited learning capacity which can result in low accuracy i.e., either a high detection rate and an increased FPR, or a low detection rate and a low FPR. This is why complex ML implementations are preferred.

To reduce the FPR while having a high detection rate, in [START_REF] Mushtaq | Whisper: A tool for run-time detection of side-channel attacks[END_REF] the authors use ensemble ML. In an ensemble ML, two or more ML algorithms are used, while the final decision is made by a majority vote. The drawback of this solution is the bigger performance overhead (8%) of using multiple ML algorithms in combination and using one specific model per attack vector. In another work [START_REF] Gulmezoglu | Fortuneteller: Predicting microarchitectural attacks via unsupervised deep learning[END_REF], the authors propose Long Short-Term Memory networks (LSTM) for detection of microarchitectural attacks in desktop and server environments. They use the LSTM to learn the behavior of the system during normal operation, which enables them to detect any deviation from it as malicious. They manage to detect attacks with 99.70% F-score, 0.125% FPR and 3.5% performance overhead. However, LSTMs are resource-intensive MLs, and while a 3.5% performance overhead is not high for server or desktop environments, it can pose limitations when deployed in an IoT device, as resources are limited. Decreasing the frequency of HPC extraction and ML deployment can reduce the overheads, but as shown in [START_REF] Polychronou | Madman: Detection of software attacks targeting hardware vulnerabilities[END_REF], in this case the ML algorithms might be vulnerable to evasive attacks, i.e., attacks whose behavior is modified in a way that the extracted HPCs are closer to the normal behavior.

The second approach implements the security mechanism in a remote system such as a cloud server. This approach reduces the performance overhead of the local implementation of the detection mechanism, since it only needs to periodically extract HPCs, but significantly increases the memory and communication overhead since we must store this extracted information before transmitting them to a remote server. In [START_REF] He | Power-grid controller anomaly detection with enhanced temporal deep learning[END_REF], the authors use LSTM and Conditional Restricted Boltzmann Machine (CRBM) in a remote system. They succeed in detecting attacks with 99.97% accuracy and have an FPR of 0.5%. In [START_REF] Krishnamurthy | Anomaly detection in real-time multi-threaded processes using hardware performance counters[END_REF], the authors use a one-class SVM and detect attacks with the accuracy of 100%. Both implementations extract HPC data every 1 ms, which significantly increases communication overhead. Considering the hundreds of other edge devices transmitting all of their extracted information, these solutions might lead to exceeding the network capacity, which can result in slowdowns and unavailability.

Both approaches seek to minimize some overheads at the expense of others. On the other hand, we find a promising approach [START_REF] Wang | Hardware performance counter-based malware identification and detection with adaptive compressive sensing[END_REF] for resource-constrained systems. In [START_REF] Wang | Hardware performance counter-based malware identification and detection with adaptive compressive sensing[END_REF], authors use information from the HPCs in combination with a remote implementation of ML, to avoid overheads in the local system. They also try to reduce the communication overhead of sending all extracted HPC samples by sending only a compressed version. However, authors found that increasing the compression rate reduces the accuracy. A compression rate of 20% and 30% showed the best detection rate. Yet, their idea is limited in that it relies on signature checking, which attack authors can avoid [START_REF] Demme | On the feasibility of online malware detection with performance counters[END_REF]. Also, they rely on matrix multiplication for local data compression, which tends to increase execution overhead exponentially with the size of the data being compressed and linearly with the compression rate. The authors measure the performance overhead to be more than 5% at a compression rate of 30%.

From the works cited above, we observe that the use of complex ML models is preferred, due to their ability to provide a high detection rate, while minimizing the FPR. On the downside, implementing these solutions locally induces an increased performance overhead, which might be restrictive for IoT devices. While, remote implementations resolve the performance overhead issue but the required bandwidth required to periodically transmit all the extracted information should be optimized, otherwise it could lead to network issues. Also, they will be totally ineffective if the network is down.

Contributions:

We propose an HPC-based mechanism allowing the detection of microarchitectural attacks and compliant with resource-limited devices. This solution is based on a local-remote approach, featuring a simple ML classifier locally to the device, alongside complex and resource-heavy ML located in a remote cloud. The local ML will first try to decide how likely a behavior is suspicious and send the samples to the cloud only if necessary for further analysis.

This solution is based on edge computing concepts and takes advantage of both local and remote approaches to accurately detect attacks, targeting a 0% FPR without imposing large overhead on the local system while minimizing bandwidth. This target of 0% FPR is introduced by the likelihood of automatic fallback mechanisms in critical IoT devices that will disrupt physical processes (e.g., health monitoring, power distribution, etc.) and which should only be triggered for good reasons. Hence, our contributions are the following:

• We propose the first HPC-based local-remote ML mechanism to detect microarchitectural attacks in resource-limited devices. To decide when to send a sample to the remote ML, we implement a two-level detection threshold scheme. Outline: The remainder of the paper is organized as follows. In Section 2, we introduce our local-remote ML mechanism allowing the detection of microarchitectural attacks and analyze it in detail. Then, in Section 3, we compare ML algorithms implemented locally, remotely, and finally the local-remote implementation. In Section 4, we adapt the approach of [START_REF] Sadaf | Intrusion detection based on autoencoder and isolation forest in fog computing[END_REF] to the needs of our proposed idea and successfully further reduce the FPR. Section 5 talks about the comparison between our solution with related works and Section 6 discusses the limitations of our solution. Finally, Section 7 summarizes our work and concludes.

Proposed solution

We propose a solution that uses edge computing techniques to detect microarchitectural attacks in constrained devices such as IoT and decrease the use of the communication bandwidth. The global architecture is represented in Figure 1 and describes a first level of detection on the local IoT devices and a second on a remote server. The edge device pre-processes the extracted HPC data to filter out the ones with low value of maliciousness, i.e., the normal HPC measurements. To be somewhat independent of a remote security solution, the tiny ML can raise an alarm when it is convinced that an attack is being carried out. This is useful in cases where the network is down and no connection to the remote solution is possible. HPC values that cannot easily be labeled either as malicious or trusted are transmitted to a remote server for further analysis. In this case, a complex ML can accurately detect malicious activities. The proposed idea allows us to move parts of the storage and processing resources away from the remote center and closer to the local device. This idea overcomes many limitations of traditional cloud computing such as latency, service delays, network outages, and reliability.

Local ML implementation

In each edge device, the local ML algorithm which processes the HPC values can be supervised or unsupervised. It reads the HPC samples and outputs a probability between 0% and 100% for each sample to be a microarchitectural attack. We refer as a sample, a snapshot of the values of the selected HPCs. The implementation, as shown in Figure 2, allows us to trust samples with a low probability of an attack. It sends samples with an intermediate probability to a remote ML for further evaluation and raises an alert if there are samples with a high attack probability. This is achieved by setting two thresholds.

The first threshold (alert threshold) acts as a trigger for detecting samples that have a high probability of being a microarchitectural attack. We choose the alert threshold based on the maximum probability obtained using the local ML for only normal training samples, plus an extra offset. This offset acts as an uncertainty level. By choosing the alert threshold as this, we are more certain that during evaluation the local ML will not raise false alerts.

The second threshold (suspicious threshold) is set to allow the samples that our local ML cannot identify with high confidence to be stored and later sent to the remote ML for further processing. MLs from related work use a probability of 50% to classify samples as malicious or normal. To compute the optimal suspicious threshold, we iteratively try different thresholds and compute the G mean , as shown in [START_REF]Correlation coefficient: Simple definition, formula, easy steps[END_REF]. We then keep as suspicious threshold the one yielding the maximum G mean . G mean is a metric that tries to find an equilibrium between FPR and True Positive Rate (TPR). Essentially, G mean will give us the probability threshold that allows us to filter as many normal samples as possible, while also maximizing the suspicious samples to raise an alert locally or sent them to the remote for further evaluation.

G mean = T P R * (1 -F P R) (1)
Subtracting an offset allows the local ML to label samples as suspicious a bit more loosely. This will allow sending malicious samples with behavior closer to normal to the remote ML. The trade-off being that more normal traffic will also be sent for remote analysis.

Remote ML implementation

Suspicious samples are stored locally then sent to a remote ML for further analysis. The local system sends suspicious samples every ∆s to the remote system. This value is chosen empirically and more analyses will be required to evaluate its optimum. The remote ML is based on a complex ML, which is capable of learning complicated behaviors. It can be either a supervised or an unsupervised ML implementation. An unsupervised ML implementation, such as an LSTM, learns only normal behavior and detects any behavior that deviates significantly from the patterns our ML mechanism is trained to identify as a normal behavior. Using MLs that learn only from normal behavior, we can potentially detect zero-day attacks by hypothesizing that they deviate from normal behavior and that the local ML succeeds in labeling them as suspicious.

The remote system examines suspicious samples it receives from the local system for differences from normal behavior and flags them as abnormal if they deviate and notifies the local system. Examples of such complex MLs are Autoencoders, one-class SVM, and LSTM networks. LSTM is a network that uses information from past samples to make predictions for current or future samples. Thus, if a remote LSTM ML is used, the additional information about the past HPC samples increases the data sent to the remote.

Benefits of a local-remote approach: Local filtering allows us to reduce the memory requirements for local storage of the extracted samples while minimizing the communication and network overhead for transmitting the samples to the remote system each ∆s. Using this localremote approach, we can filter most of the extracted data under normal operation, while only transmitting remotely data under attack. In the following sections, we evaluate various local-remote implementations and present their overhead and detection capabilities.

Solution evaluation

In this section, we evaluate various local or remote ML models individually and their combination using several detection metrics. We also evaluate the overheads incurred in the local system and the data successfully filtered. Section 3.1 will introduce our experimental platform and the choice of HPC we use for monitoring. Section 3.2 will present our experimental results, justifying our final choice of ML algorithms. In Section 3.3, we evaluate the filtering followed by the two-level threshold approach and finally, in Section 3.4, we optimize the memory required to save the extracted HPC data labeled suspicious.

Experimental platform

Our experimental platform featured in Figure 3 is based on a Raspberry Pi4 Model B running on Ubuntu 20.04.2 LTS. Its processor is widely used in embedded devices with high resources requirements such as I-IoT gateways and has four ARM Cortex-A72 cores running at 1.5 GHz. Each core of the processor provides 84 HPCs and enables the extraction of measurements from six registers simultaneously. As proposed in [START_REF] Polychronou | Madman: Detection of software attacks targeting hardware vulnerabilities[END_REF], we extract measurements from the HPC registers each 1 ms to be able to detect cache attacks integrating eviction techniques. A dedicated kernel module mainly based on an assembly code was used to extract the samples to limit the performance overhead.

To demonstrate our idea, we use several microarchitectural attacks as test vectors. These include CacheSCA variants, Spectre variants, Meltdown, and Rowhammer. Also, we include obfuscated (evasive) variants as suggested in [START_REF] Polychronou | Madman: Detection of software attacks targeting hardware vulnerabilities[END_REF] by inserting nop or sleep instructions in the attack code to hide malicious activity. Most of these attacks are publicly available from Github [START_REF]Armageddon: Cache attacks on mobile devices[END_REF], [START_REF] Yuval | Mastik: A micro-architectural side-channel toolkit[END_REF], [START_REF] Jinbum | Csca (crypto side channel attack)[END_REF], [START_REF]Flush + flush[END_REF], [START_REF]Attempt of implementation of spectre for armv7a[END_REF], [31], [START_REF] Cosmin | Poc code implementing variant 3a of the meltdown attack for aarch64[END_REF] and modified to be able to run on the targeted processor. For our benign applications, we use MiBench [START_REF] Matthew R Guthaus | Mibench: A free, commercially representative embedded benchmark suite[END_REF] and PARSEC [START_REF] Bienia | The parsec benchmark suite: Characterization and architectural implications[END_REF], which are industry standard embedded system benchmarks that cover a wide range of applications. Our library contains 29 attacks and 72 normal applications.

As the number of events that can be measured simultaneously is limited to six on our experimental platform, it is essential to select the optimal subset of HPC registers to monitor in order to obtain the best detection results. There are different ways to identify the best suitable HPC registers:

• A first solution is to use HPC registers related to different hardware units of the processors: cache memory, bus, TLB, etc. • A second solution is to use generic HPC registers, that is to say, events that are implemented in most of the CPU cores (Intel, AMD, ARM, RISC-V).

• Feature extraction methods such as Pearson correlation [START_REF]Correlation coefficient: Simple definition, formula, easy steps[END_REF] or Mutual Information [START_REF] Miller | Entropy and mutual information[END_REF] are mathematical methods to calculate the amount of information provided by a hardware event in order to detect or classify data. • A theoretical study was proposed in the review [START_REF] Polychronou | A comprehensive survey of attacks without physical access targeting hardware vulnerabilities in iot/iiot devices, and their detection mechanisms[END_REF] to present the most interesting events to detect microarchitectural attacks.

Finally, we selected six HPC events using Mutual Information method. This requires the extraction of all available HPCs in the ARM cortex-A72 processor core during the execution of normal and malicious applications. The experimental setup described in Figure 3 was used to extract these measurements. The methodology can be divided in multiple steps:

• Step 1: Configuration of the extraction of the HPC events and the monitoring interval.

Evaluation of different ML algorithms

For the training of the ML algorithms? we used a 70/30 random split of the different applications. Since some applications have a longer execution time than others, we used time-series data augmentation techniques as proposed in [START_REF] Kenji | An empirical survey of data augmentation for time series classification with neural networks[END_REF] to balance the number of samples between each application, either by upsampling or downsampling. Such techniques are time warping, magnitude warping, window warping, scaling, and window slicing. After augmenting our dataset? we use 20% of the training data for validation using stratified sampling [START_REF] Zeng | Distribution-balanced stratified cross-validation for accuracy estimation[END_REF].

As a first step, we identify how each ML algorithm performs on our classification problem. Our motivation for evaluating the performance of each ML classifier is to show that simple local MLs are capable of identifying malicious samples but have a high FPR. This allows us to demonstrate the need to use complex MLs that have a lower FPR, and finally the advantages of a local-remote ML solution. We selected two local ML classifiers for testing: (i) Linear SVC (LSVC), and (ii) AdaBoost using five Logistic Regression classifiers. We also select two remote ML classifiers: (i) LSTM, and (ii) LSTM Autoencoder (LSTMAE) with each of them using the seven past samples to predict the current one. For the evaluation, we use the following metrics: TPR (or detection rate), and FPR. TPR is a metric that measures how well we identify True Positives (TP) and FPR is the percentage of negative samples falsely classified as positive relative to the total number of negative samples. We pay significant attention to FPR because we argue that low FPR is as important as high TPR for resource-limited and critical devices. In Table 1, we display results according to the different classification metrics for each of the classifiers. These results for the simple MLs are obtained by using as the classification threshold, the 50% probability of a sample being a microarchitectural attack as in other state-of-theart works. For the complex MLs, we use as the classification threshold, the quantile (99.85%) of the distribution of the mean square of the reconstruction errors of the normal training dataset as in [START_REF] Oleksandr I Provotar | Unsupervised anomaly detection in time series using lstm-based autoencoders[END_REF].

Local MLs have a high TPR (∼ 99.70%) but also a high FPR (0.68% and 1.63%) while the more complex MLs have lower FPR (0.03% and 0.45%) than the simple MLs. The lower TPR of the complex ML is caused by the simple MLs using classification, able to learn patterns from the input and knowing the final label, while the complex perform anomaly detection and detect as malicious any input that greatly deviates from the normal dataset. This is also why remote MLs have lower FPR, since they are trained only with normal data, which helps them to recognize most normal samples. Yet, having a 0.5% FPR means that 5 samples out of 1000 would be erroneously detected as malicious. With a sampling rate of 1 ms, this would potentially mean 5 false alarms every 1 seconds. In Table 2, we observe how the combination of the simple local ML with the more complex remote ML responds to this classification problem. As we can see, the TPR remains high (92.66%) and the FPR low (0.13%) when using the combination of AdaBoost and LSTM AutoEncoder7 algorithms. Benefits of a local-remote approach: First minimizing the FPR is desirable since one FP is enough to label a whole application as malicious. As stated in Section 1, frequently taking actions due to an alarm during normal operation can make the device unusable. Furthermore, the TPR remains high, which allows us to capture as much malicious activity as possible and only need one timing window with high anomaly score to detect a malicious app. The TPR is lower than the simple single-level threshold MLs, since the local part of the local-remote only raises alerts for high probability samples and transmits the suspicious for further evaluation in the remote. Also, attacks do not execute only malicious actions in their whole execution, and the remote ML will recognize such parts as normal, and not as attacks as indicated in our labeling effectively lowering the TPR.

Edge-device Local ML filtering

In this section we evaluate the filtering succeeded by the two-level threshold approach. We focus on the filtering succeeded during normal operation only, since this is the state of the device in most of its operation and we do not want to overflow the communication interface with limited value data under this condition. From Table 3 we can observe the filtering succeeded under normal operation, when the local ML is configured as AdaBoost (same case as in Table 2), monitoring the system each 1 ms, monitoring six 4 bytes HPC counters per core, and 4 cores in total, while transmitting the data to the remote each 1 minute. The total size of data extracted from the system per minute of execution is 5760kB. Benefits of a local-remote approach: From Table 3, we can see that our approach can successfully filter more than 99% of the extracted HPC data under normal operation. This is due to the local ML being very successful to label as normal benign applications (keeping them under the suspicious threshold). This allows us to dramatically reduce the bandwidth required under normal operation where solutions containing only a remote ML will send all samples to the cloud.

Memory & Detection Time Optimization

In this subsection we optimize the memory required to save the extracted HPC data labeled suspicious. Furthermore, we optimize the detection time, since under attack we would like to detect the attacks before the specified ∆s = 1 minute and further waiting for the remote ML to give us the final decisions. To succeed with the above, we make the two following observations from Figure 4 and Figure 5: • Under only normal operation the saved suspicious data does not exceed a certain value, which in this case as seen in Figure 5 is not more than 50KB.

• When an attack executes on the system, the rate of saving suspicious data in local storage increases. We can observe that in Figure 4 in periods 2-3, 5-6, 8-9. So to optimize the memory required and the detection time, we set the size of the local storage to the calculated maximum amount of data saved and transmitted under normal operation, so under normal operation we do not exceed this size. For AdaBoost this is 54 kB. If under attack, we require more memory to save the extracted HPC samples, and rather than saving more data and as soon as the memory is full, we send the data directly to the remote to have a quicker detection time. As mentioned in the previous observations, under attack the rate of suspicious data saved is greater than under normal operation, which most probably will overflow the local storage.

This implementation choice allows us to only specify the necessary memory for local storage, rather than using a 5760 KB memory, and also under attack we transmit the data faster in most cases than waiting the specified ∆s.

False Positive Minimization Using an Isolation Forest

In the previous section, we successfully reduced the required communication bandwidth and optimized the memory and detection time. But, as observed from Table 2, the FPR of the local-remote might be lower than both complex and single MLs used individually, but it can still be minimized to avoid unnecessary false alarms. To minimize the FPR, we adapt a solution proposed by [START_REF] Sadaf | Intrusion detection based on autoencoder and isolation forest in fog computing[END_REF] as can be seen in Figure 6. Sadaf et al. use an Isolation Forest [START_REF] Fei | Isolation forest[END_REF] to optimize their classification metrics. An Isolation Forest is a technique to detect/find outliers in a set of data as the samples that greatly differ from others. In their implementation as seen in Figure 6, the input samples are predicted by a ML. As their ML is not perfect, it has some FPs and some FNs. In their hypothesis, FPs are outliers among the rest of the TPs and FNs are outliers among the majority of TNs. By using then an Isolation Forest in the positives, they can find the FPs and change their final label to negative increasing the correct predictions and classification metrics. In our case to minimize the FPR, we adapt their approach by also using the memory and detection time optimization presented before in Section 3.4. To do this we make the following hypotheses:

• If the remote ML received the data before the expected ∆s, we trust its decisions since this most probably happened due to the execution of an attack.

• If the remote ML received data at the expected ∆s, we can expect to be under normal operation and must be careful for FPs. Thus, we double-check the remotes ML positive decisions using an Isolation Forest. In Figure 7, we can see both our pseudo-algorithm and our technique to adapt the approach proposed by Sadaf et al. When the remote received the data as expected at ∆s, for each remote ML positive decision, we also check if the suspicious samples are inliers or outliers in the Isolation Forest. If the Isolation Forest indicates that the sample is an inlier, i.e., it predicts that it is similar with a large pool of normal samples used for the remote ML training, then we reset the decision to negative, otherwise we notify the embedded device of the presence of an attack. As we can see from Table 4, the use of the Isolation Forest to doublecheck remote ML's decisions, can successfully reduce the FPR to 10 -5 % compared to 0.13% when not using it.

State-of-the-Art Comparison

Table 5 presents how our work compares to other approaches in the SOTA. This is not a comparison on the same dataset, since we use different attack vectors and normal libraries, in addition to the different experimental platform, but it shows the contributions of our approach as all articles try to detect the same microarchitectural When the threat model has more attack vectors (rows 5-), then more complex MLs are used, such as ensemble ML and LSTM, which keep the accuracy high, while minimizing the FPR. On the downside, we can observe that WHISPER [START_REF] Mushtaq | Whisper: A tool for run-time detection of side-channel attacks[END_REF] has an overhead of 8%, and For-tuneTeller an overhead of 3.5%. These overheads might not be significant in the targeted desktop/server systems, but using these solutions on an embedded device could be challenging. Wei et al. [START_REF] Wei | Using power-anomalies to counter evasive micro-architectural attacks in embedded systems[END_REF], Kuruvila et al. [START_REF] Peedikayil Kuruvila | Explainable machine learning for intrusion detection via hardware performance counters[END_REF], and Wang et al. [START_REF] Wang | Enabling micro ai for securing edge devices at hardware level[END_REF] propose solutions for embedded systems. While Wei et al. succeed having high accuracy and low FPR, they use an LSTM, which is a resource demanding ML algorithm, and it could be challenging fitting it in a resource-limited system. On the other hand, Kuruvila et al and Wang et al. use simpler MLs to reduce the overheads imposed on the embedded device, but as we see from the table the FPR is high (or precision is low). In comparison, our solution succeeds in keeping the detection accuracy high (98.75%), having minimal FPR (∼ 0%) and imposing a minimal overhead (0.8%) on the edge-device.

Finally, compared to the solution proposed by [START_REF] Wang | Hardware performance counter-based malware identification and detection with adaptive compressive sensing[END_REF], which was able to compress the extracted data by 20-30% while keeping the overhead around 5%, we see that our solution can filter up to 99% while the overhead is less than 1%.

Discussion

In this section we discuss some implications of our findings and limitations of our approach and propose some ideas to improve future solutions.

Overhead in more constrained devices: In Section 5 and more precisely in Table 5, we mentioned that the overhead imposed by our solution in the Raspberry PI4 is less than 1%. However, this kind of platform has high computation resources and is considered as a complex IoT device. To validate that our proposed solution can be integrated in more resources-constrained devices, more experiments should be performed to evaluate the overhead induced by HPC monitoring with tiny ML.

Non-determinism: Some articles such as [START_REF] Das | Sok: The challenges, pitfalls, and perils of using hardware performance counters for security[END_REF] address issues related to the use of HPCs. One of these problems is the non-determinism of their values especially due to the context switch of the processor or hardware interrupts. We agree with all these observations but we still think that hardware performance counters can be used in constraint systems with simple functionalities such as IoT and I-IoT. Moreover, if the detection of all families of malware with this method can be discussed, the state of art already shows that HPCs is particularly efficient for microarchitectural attacks.

Limited datasets: Botacin et al. [START_REF] Botacin | Why we need a theory of maliciousness: Hardware performance counters in security[END_REF] recently discuss about the use of a limited dataset to detect microarchitectural attacks and other kinds of malware with ML algorithms. In order to circumvent this issue, we choose to use evasive attacks based on techniques proposed in [START_REF] Polychronou | Madman: Detection of software attacks targeting hardware vulnerabilities[END_REF]. These include the insertion of N OP or sleep instructions in between sensitive tasks to modify the output counts to range closer to normal behavior. We also use some data augmentation techniques to increase the size of some applications. We can still improve by finding more hidden strategies to obfuscate the attack scripts or use GAN (Generative Adversarial Network) based Augmentation as proposed in [START_REF] Kim | Gan based augmentation for improving anomaly detection accuracy in host-based intrusion detection systems[END_REF].

Improving the security of the solution: It was proven in [START_REF] Basu | A theoretical study of hardware performance counters-based malware detection[END_REF] that an advanced attacker with knowledge of our simple local ML parameters, could hardly develop a code that produces behavior similar to normal while still succeeding the attack. However, the current solution is implemented in software, which means that the local security supervisor including the HPC extraction, the tiny ML and the publishing of suspicious samples implementation and the other applications share resources. This issue still introduces a vulnerability that can be used by an attacker to circumvent or break the solution with a malware. An improved solution will be to implement the local detector as a trusted application in a TEE (Trusted Execution Environment) such as Trustzone or as a dedicated hardware implementation as it was proposed in [START_REF] Thevenon | iMRC: Integrated monitoring & recovery component, a solution to guarantee the security of embedded systems[END_REF].

Network availability: If the network is down or victim of a Denial of Service attack, our approach will only rely on the ability of the local ML to detect the attacks. Still, it provides a level of security since it can detect high probability samples. Depending on the criticality of the user application, the lack of communication between the IoT node and the control server can also be considered as an attack.

Periodicity to send data to the control server: Another parameter we would like to investigate is ∆s. In this work it was empirically set to one minute, but more research needs to be done that takes into account communication overhead, detection latency, encryption of suspicious data, and storage overhead. Sending data more frequently to the remote can reduce the detection time, but also increases the overheads, while decreasing ∆s reduces the overheads but increases detection time.

Malware detection: In this paper, we choose to focus on the detection of microarchitectural attack as this class of attacks is complex to circumvent. This kind of attacks cannot really be considered as a class of malware but rather as a part of a malware used to gain privileges or steal sensitive data. As some malware do not use these methods, it is required, to detect more categories of attacks to update our dataset to include complete IoT malware such as BashLite, IoTReaper or Mirai. Since these malware do not stress as much as microarchitectural attacks the hardware, it will probably necessitate more complex ML algorithms on the local device and the remote server or samples from different sources than HPCs.

Conclusion

Embedded devices face an increasingly number of microarchitectural attacks. Such attacks often require hardware changes to be circumvented and detection is generally preferred over mitigation. Several works have been proposed that effectively detect microarchitectural attacks, but without considering the limitations of embedded devices such as computing power, memory, and bandwidth. We have shown that local solutions can have a high detection rate but also a high FPR, while remote solutions are effective but require a large amount of resources and network availability.

This work proposes a solution for detecting attacks on low-resource devices. We propose a local-remote implementation that minimizes the performance, memory, and communication overhead in edge devices while having a high detection rate and minimal FPR. The overall approach benefits from the presence of complex ML algorithms in a cloud to take appropriate decisions but is fully able to work in case of network downtime. We also evaluate the proposed local-remote idea in terms of various metrics. We show that the local system successfully filters 99% of the normal extracted data, which reduces the bandwidth in normal operation. Furthermore, the local-remote mechanism increases precision compared to a purely single level threshold implementation, while the FP minimization strategy using an Isolation Forest, as applied in the context of this solution, can reduce FPR to 10 -5 %, preventing unneeded attack responses. Finally, we discuss the design choices and limitations of this work.

Multiple paths can be explored as future works. First, many parameters can be tweaked to further reduce overhead (∆s, changing local implementation to an FPGA/ASIC solution). This could also reduce the attack surface of the local detection mechanism itself. Also, this work is currently limited to microarchitectural attacks. Many other kinds of attacks target embedded devices and in particular IoT (malware exploiting software flaws, denial of service botnets, cryptolockers, reverse shells, etc.). As these attacks will less exploit the hardware, we expect that they will be harder to detect with simply HPCs. Experimental evaluations should then be performed on our ability to detect other kinds of attacks with only HPCs and other signals should be proposed.

Figure 1 .

 1 Figure 1. Global overview of the proposed solution.

Figure 2 .

 2 Figure 2. Two-level detection threshold implementation.

Figure 3 .

 3 Figure 3. Testbed used to identify best features.

Figure 4 .

 4 Figure 4. Data stored to the local memory per second (red dotted line) and sent to the remote ML for further evaluation each ∆s 1 minute (purple triangles). The shaded areas indicate the period where the system is under attack.

Figure 5 .

 5 Figure 5. Data stored to the local memory per second (red dotted line) and sent to the remote ML for further evaluation each ∆s 1 minute (purple triangles) under normal operation.

Figure 6 .

 6 Figure 6. Isolation Forest used by Sadaf et al. [30] to increase classification metrics.

Figure 7 .

 7 Figure 7. Isolation Forest technique used by Sadaf et al. adapted for our approach.

  • Step 2: Execution of benign and malicious applications. Extraction of the raw traces of HPC values from a computer. Use of Mutual Information method to evaluate and identify the 6 best HPCs events.The top six features we obtained with this methodology for microarchitectural attacks detection in the context of IoT are the following:

• Step 3: • Step 4: • ISB_SPEC: This event counts each instruction barrier speculatively executed. • L1D_TLB_REFILL: This event counts any L1 data TLB refill. • BR_IMMED_SPEC: This event counts each branch speculatively executed. • L2D_CACHE_REFILL: This event counts any L2 unified cache refill • BR_MIS_PRED: This event counts any branch which is not correctly predicted. • MEM_ACCESS_LD: This event counts memory accesses due to load instructions

TABLE 1

 1

	. CLASSIFICATION METRICS FOR THE DIFFERENT ML
	ALGORITHMS SIMPLE (LINEARSVC & ADABOOST) AND MORE
	COMPLEX (LSTM7 & LSTM AUTOENCODER7).
	Single Level Threshold	TPR	FPR
	LinearSVC	99.75% 1.63%
	AdaBoost (Logistic Regression)	99.70% 0.68%
	LSTM7	72.99% 0.03%
	LSTM+ AutoEncoder7	92.41% 0.45%

TABLE 2 .

 2 CLASSIFICATION METRICS FOR THE LOCAL-REMOTE.

	Two Level Threshold	TPR	FPR
	AdaBoost + LSTM7	73.09% 0.02%
	AdaBoost + LSTM AutoEncoder7	92.66% 0.13%

TABLE 3 .

 3 DATA SEND PER MINUTE UNDER NORMAL OPERATION AND PERCENTAGE OF FILTERING WHEN 5760KB OF HPC DATA ARE EXTRACTED PER MINUTE.

	Local ML	Number of bytes send	filtering
	(filtering only)	per minute	percentage
	AdaBoost (Logistic Regression)	39kB	99.32%

TABLE 4 .

 4 CLASSIFICATION METRICS FOR THE LOCAL-REMOTE ML with and without THE ISOLATION FOREST FOR FP REDUCTION.

	Two Level Threshold	TPR	FPR
	AdaBoost + LSTM AutoEncoder7	92.66%	0.13%
	AdaBoost +
	LSTM AutoEncoder7	92.66%	∼ 0%
	+ Isolation Forest

TABLE 5 .

 5 COMPARISON OF OUR LOCAL-REMOTE IMPLEMENTATION TO THE RELATED WORKS. As we can see from the table, when the threat model has limited attack vectors (as in rows 1-4), simple ML models such as Logistic Regression can succeed in detecting the attacks with high accuracy and low FPR.

	Detection Mechanism	Attacks	Accuracy F-score	FPR or Precision	Overhead	System	Local or Remote
	Mushtaq et al. [23] Logistic Regression (No Load)	Flush+Reload	99.51%		0.48% FPR	0.94%		Local
	Mushtaq et al. [23] SVM (No Load)	Flush+Reload	98.82%		0.397% FPR	1.29%		Local
	Mushtaq et al. [23] Logistic Regression (No Load)	Flush+Flush	91.73%		0% FPR	1.10%		Local
	Mushtaq et al. [23] SVM (No Load)	Flush+Flush	97.42%		0% FPR	0.79%		Local
	WHISPER [24]
	Ensemble Learning	CacheCSA,
	One model per attack	(F+F, F+R, P+P),	>97.05%			<8%		Local
	(DT, RF and SVM)	Spectre, Meltdown
	(No Load)
	FortuneTeller [11] LSTM	Spectre, CacheCSA, (F+F, F+R, P+P), Meltdown, Rowhammer		99.70%	0.125% FPR	3.50%		Local
	Wei et al. [35] OC-SVM	Prime + Probe, Spectre, Rowhammer, Evasive	<98.63%		<0.5% FPR
	Wei et al. [35] LSTM	Prime + Probe, Spectre, Rowhammer, Evasive	<99.06%		<0.5% FPR
	Kuruvila et al. [19] Random Forest	Flush + Flush, PNScan, Spectre, Meltdown, Rowhammer, BashLite	89.90%	89.91%	89.25% Precision	<1.22%		Local
	Wang et al. [33] MPL	CacheCSA, (F+F, F+R, P+P), Spectre	<98.9%	<97%	5.3% FPR	<3.2%
	Wang et al. [33] Logistic Regression	CacheCSA, (F+F, F+R, P+P), Spectre	<98,9%	91.90%	14.9% FPR	<3.23%
	Ours AdaBoost + LSTM AutoEncoder7	Spectre, Rowhammer, Meltdown, Evasive CacheCSA (F+F, F+R, E+R, P+P),	98.75%	96.19%	10 -5 % FPR	0.80%		Local Remote
	attacks.

Acknowledgements

This work was supported by the French National Agency in the framework of the "Investissements d'avenir" (future-oriented investments) program (ANR-10-AIRT-05).