CHANNEL

DESCRIPTION

TECHNICAL FIELD

The present invention relates to the computer systems sector. In particular, the invention relates to a method for controlling the communication channel according to the Bluetooth standard by a software application installed on an electronic device.

BACKGROUND

The Bluetooth communication standard, abbreviated to 'BT', is widely used in the management of the so-called personal networks or PAN - English acronym for Personal Area Network. In fact, the Bluetooth standard permits establishing a stable, high-speed and low-energy consumption short-range communication between electronic devices.

In particular, the Bluetooth standard is used for the connection to a first device - such as a smartphone, tablet, personal computer, etc. - of another similar device - for example another smartphone - and/ or one or more second devices belonging to different types - such as smartwatches, fitness trackers, wireless headphones, medical devices, smartcard/ credit card readers, printers, vehicles , etc.

The pairing between the first device and the second device for the communication according to the Bluetooth standard occurs at the level of the entire device. In other words, once a Bluetooth communication is established between two devices, this can be exploited by one or more software applications installed on one of the two devices, in particular on the first device, in order to transfer information from one device to another.

In the case of devices implementing the Android operating system, once they are paired with another device, there is a lack of control over which of the software applications enabled to communicate via Bluetooth actually connect to the external device, thus leaving the possibility of malicious software applications to connect to the second device and acquire information therefrom in a transparent manner to the user.

This problem is exacerbated in the case of the variant of the Bluetooth standard called Bluetooth Low Energy - often abbreviated to 'BLE'. Bluetooth Low Energy provides that multiple software applications being executed on the first device can communicate via the Bluetooth communication channel at the same time. In this case, it is even more difficult to detect a malicious software application that improperly exploits the Bluetooth communication.

In fact, the Applicant has determined that it is possible to design procedures which, once implemented in a first device - for example, masked by, or included in non-suspicious software applications installed by the user on the first device - unduly acquire sensitive data - for example, patient's biometric data - provided by a second device coupled via Bluetooth to the first device in a completely transparent manner to the user.

In order to solve this problem, several expedients have been proposed. For example, in Muhammad Naveed, Xiaoyong Zhou, Soteris Demetriou, XiaoFeng Wang, Carl A Gunter, " Inside Job: Understanding and Mitigating the Threat of External Device Mis-Bonding on Android", ISOC Network and Distributed Computing Security (NDSS), 2014 it is proposed a protection protocol acting at the operating system level and comprises binding a second device to an official software application for said device in a unique way.

In Soteris Demetriou, Xiaoyong Zhou, Muhammad Naveed, Yeonjoon Lee, Kan Yuan, XiaoFeng Wang, Carl A Gunter, "What's in Your Dongle and Bank Account? Mandatory and Discretionary Protection of Android External Resources", NDSS Symposium, 2015, it is proposed implementing a security system that operates at the middleware and kernel level so as to block Bluetooth communication attempts made by malicious software applications.

In Fenghao Xu, Wenrui Diao, Zhou Li, Jiongyi Chen, Kehuan Zhang, "BadBluetooth: Breaking Android Security Mechanisms via Malicious Bluetooth Peripherals", NDSS Symposium, 2019, a modification of the operating system is proposed regarding the management of the permissions to communicate with a second device configured to define a list of software applications that are allowed to communicate with a particular second device.

In Nan Zhang, Kan Yuan, Muhammad Naveed, Xiaoyong Zhou and XiaoFeng Wang, "Leave Me Alone: App-level Protection Against Runtime Information Gathering on Android", IEEE Symposium on Security and Privacy, 2015, it is proposed to put in a state of pause or stand-by all software applications operating in the background and that are deemed potentially malicious while a primary application is being executed in the foreground.

In summary, the defence mechanisms proposed in the aforementioned articles propose substantial modifications to the operating system - in particular, the Android operating system - executed on the first device. These expedients therefore go far beyond the skills of a generic user and require to be approved and integrated into the operating system by the body that develops and releases it - for example, Google Inc. in the case of Android.

In Pallavi Sivakumaran, Jorge Blasco, "A Study of the Feasibility of Co-located App Attacks against BEE and a Large-Scale Analysis of the Current Application-Layer Security Landscape", 28th USENIX Security Symposium, 2019, it is believed that the only solution to ensure the security of information exchanged via low-energy Bluetooth communication is to implement a security system in the application layer of the ISO/OSI model of the communications between device and second device.

However, redefining the Bluetooth protocol or modifying the ISO/OSI model by introducing additional security layers are rather complex low-level solutions that require acceptance by standardization bodies, as well as by device and software application manufacturers .

Furthermore, in Muzammil Hussain, Ahmed Al-Haiqi, A. A. Zaidan, B. B. Zaidan, M. Kiah, Salman Iqbal, S. Iqbal, Mohamed Abdulnabi, "A security framework for mHealth apps on Android platform ", Computers & Security, Pages 191-217, Volume 75, 2018, it is proposed to introduce a new layer of security and of privacy policies that directly act on the various layers of the Android operating system.

Even in this case, the proposed expedient goes far beyond the normal skills of the general user and requires substantial modifications to the Android operating system.

In addition, it is known to implement applications in so-called sandboxes, i.e. dedicated memory portions to limit the operation thereof, for example, US 2019/065736 describes a method for preventing malicious applications from exploiting the application services. This method may include: identifying an attempt to initiate an application service by an application, where the application is executed in a sandbox environment, determining that the application poses a potential security risk, asking to a user of the computer device to remedy the potential security risk posed by the application by executing a security action and while waiting for the user to execute the recommended security action, protecting the computer device by blocking the attempt to initiate the application service by the application.

US 2013/104232 otherwise describes a security device which provides a 'secure deployment environment' for a wireless communication device. The security device connects to the wireless communication device via a standard connection interface without requiring modifications to the wireless communication device.

Finally, WO 2016/032563 describes a complex system for guaranteeing the security of transactions carried out via electronic devices. In detail, an emulator instantiated on a device and configured to emulate an integrated circuit having a set of instructions different from the integrated circuit of the device itself. Furthermore, a host operating system is executed on the emulated integrated circuit. This host operating system is configured to communicate with a hosting operating system being executed on the device via an emulated network interface of the emulator. Under the control of one or more processes of the host operating system, a request is received on a first secure communication channel from an application being executed on the hosting operating system to authorise a transaction. Furthermore, based on the received request, the user's input is obtained from an input device of the hosting device and transformed into verification data. A second secure communication channel other than the first one is established with a remote system via the emulated network interface and a request on the second channel is sent to the remote system to authorize the transaction based on the verification data. An authorization result is received from the remote system via the second secure communication channel and a response is sent to the application on the first secure communication channel indicating the authorization result.

OBJECTS AND SUMMARY OF THE INVENTION

An object of the present invention is to overcome the disadvantages of the prior art.

In particular, it is an object of the present invention to present a method for controlling the Bluetooth communication channel so as to prevent an undue exchange of information between an application being executed on a first electronic device with a second device coupled to the first electronic device, with no need for a modification of an operating system implemented by the first device and/or without requiring special skills from the user of the first device.

Herein the expression 'Bluetooth communication channel' or 'communication via Bluetooth' are intended to indicate the communication channel based on radio frequency signals that uses radio resources (for example, bandwidth, maximum transmissible power, etc.) in accordance with the Bluetooth® specifications defined by the Bluetooth Special Interest Group.

A further object of the present invention is to present a software application which is simple to use for a non-expert user, and which is at the same time capable of blocking any unauthorized attempt to connect via the Bluetooth communication channel.

These and other objects of the present invention are achieved by means of a system and a method incorporating the features of the accompanying claims, which form an integral part of the present description.

According to a first aspect, the present invention is directed to a method for controlling communications via the Bluetooth communication channel in an electronic device, wherein the electronic device is configured to execute an operating system. The method comprises the steps of: creating a virtual environment configured to execute an instance of at least one software application stored on a first electronic device; executing in the virtual environment a software application enabled to communicate via the Bluetooth communication channel; identifying an attempt to communicate via the Bluetooth communication channel by said software application with a second electronic device coupled to the first electronic device; if a communication attempt via the Bluetooth communication channel is identified, blocking the communication attempt and requesting an authorization by a user of the first electronic device, and allowing said communication via the Bluetooth communication channel in the presence of an authorization provided by said user, or preventing said communication via the Bluetooth communication channel in the absence of an authorization by said user.

In particular, creating a virtual environment comprises: allocating a dedicated memory area for executing a control software application; instantiating the control software application inside said dedicated memory area, and the control software application executes the virtual environment inside the dedicated memory area, said virtual environment being a replica of said operating system.

In detail, the virtual environment is a replica of the operating system being executed on the first device, or native operating system, in the sense that it is not a simple secure memory area or, sandbox, commonly used to execute software applications - as is the case in Android - but it is an instance of a software application that allows the execution of multiple applications, preserving the functionality thereof and ensuring access to all the services of the native operating system.

Thanks to this solution it is possible to easily control any communication via the Bluetooth communication channel between two devices. In particular, executing one or more software applications enabled to communicate via Bluetooth in a virtual environment instead of directly in the real operating system allows identifying, suspending and/ or blocking any attempt to communicate via the Bluetooth communication channel made by such software applications.

In particular, this solution can be implemented in a simple way with no need to alter the real operating system of the first device and/or the Bluetooth communication protocol. For example, said method can be implemented without having privileged user's permissions (referred to in the jargon as root or superuser) in the operating system, in particular Android, implemented on the first electronic device.

Furthermore, this solution turns out to be effective in preventing unwanted Bluetooth communications regardless of the specific expedients implemented in a malicious software application. In one embodiment, the method further comprises the steps of: identifying software applications enabled to communicate via the Bluetooth communication channel stored on the first electronic device; selecting at least one software application enabled to communicate via the Bluetooth communication channel to be executed in the virtual environment, and in which the step of executing in the virtual environment a software application, enabled to communicate via the Bluetooth communication channel, comprises identifying a command to execute at least one selected software application and creating an instance of said selected software application in the virtual environment.

Thanks to this solution it is possible to automate the execution in the virtual environment of one or more applications of which the verification of any attempts to communicate towards the second device is wished.

In one embodiment, the step of identifying an attempt to communicate via the Bluetooth communication channel by said software application with a further electronic device coupled to the first device via a Bluetooth communication channel comprises: identifying the second electronic device with which said at least one software application attempts to initiate a communication via the Bluetooth communication channel, and wherein the method further comprises the step of: providing the user with an identifying indication of the second electronic device with which said software application attempts to initiate a communication via the Bluetooth communication channel.

Thanks to this solution it is possible to allow the user to more simply discriminate when a software application attempts to execute a potentially undue communication with the second device via the Bluetooth communication channel. This solution is particularly useful when the first device is coupled simultaneously to several devices.

In one embodiment, the method further comprises the step of defining the second electronic device towards which said software application is enabled to communicate via the Bluetooth communication channel.

In this case, the step of identifying an attempt to communicate via the Bluetooth communication channel by said software application with a further electronic device coupled to the device comprises: identifying the second electronic device with which said at least one software application attempts to initiate a communication via the Bluetooth communication channel, whereas the step of blocking the communication attempt and requesting an authorization by a user of the first electronic device comprises: verifying that the second device with which said software application attempts to initiate a communication via the Bluetooth communication channel corresponds to the second electronic device previously defined.

Finally, the step of allowing said communication comprises: allowing said communication via the Bluetooth communication channel if said correspondence is verified.

In this way it is possible to identify with greater precision possible malicious attempts to communicate via the Bluetooth communication channel executed by one of the software applications stored on the first device.

In one embodiment, the step of preventing said communication via the Bluetooth communication channel in the absence of an authorization to proceed provided by the user of the electronic device comprises: when the second device with which the software application attempts to initiate a communication via Bluetooth does not correspond to at least one second electronic device previously defined, asking confirmation to the user whether to allow or prevent such communication via the Bluetooth communication channel.

In this way, it is thus allowed to limit the interactions requested to the user for blocking malicious attempts to communicate via Bluetooth.

In one embodiment, the control software application is configured to intercept and suspend any system call executed by the at least one software application being executed in the virtual environment and to route or to block to the operating system being executed on the first electronic device according to whether said authorization is provided or said authorization is not provided, respectively.

In this way it is possible to ensure the correct operation of the software application executed in the virtual environment, while allowing a complete control over its ability to communicate via Bluetooth.

A different aspect of the present invention relates to a software product for computer configured to implement the method according to any one of the previous claims. In one embodiment, the software product is configured to be executed in a version of the Android operating system developed by Google Inc.

This solution allows obtaining the advantages offered by the method according to one of the embodiments set forth above in a simple and intuitive way even for a user without particular computer skills and it can be used in a wide range of devices implementing the same operating system - in particular a version of the Android operating system - regardless of the specific hardware characteristics of the devices.

In particular, this software product can allow or block communications via Bluetooth between other software applications stored on a first electronic device and a second device coupled to the first one via a Bluetooth communication channel, without requiring special permissions and/ or altering the overall operation of the device.

Another aspect of the present invention relates to an electronic device, which comprises a control module, a memory module and a Bluetooth communication module. The control module is configured to implement one or more software applications stored in the memory module. Furthermore, the control module is configured to implement the method according to any of the embodiments set forth above.

A device with these characteristics will enjoy the same advantages set forth above in relation to the various embodiments of the method.

Further features and advantages of the present invention will be more apparent from the description of the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described below with reference to some examples, provided for explanatory and non-limiting purposes, and illustrated in the accompanying drawings. These drawings illustrate different aspects and embodiments of the present invention and, where appropriate, reference numerals illustrating similar structures, components, materials and/or elements in different figures are indicated by similar reference numbers.

Figure 1 schematically illustrates a pair of electronic devices configured to communicate with each other via a Bluetooth communication channel in which it is possible to implement the method according to the present invention;

Figure 2 schematically illustrates an electronic device configured to execute a software application implementing the method according to the present invention;

Figure 3 is a flow diagram of a method according to an embodiment of the present invention, and

Figure 4 schematically illustrates an instance of a software application for controlling Bluetooth communications implemented in the memory resources of one of the electronic devices of Figure 1 according to an embodiment, and

Figure 5 is a flow chart of a method according to an alternative embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

While the invention is susceptible to various modifications and alternative constructions, certain preferred embodiments are shown in the drawings and are described hereinbelow in detail. It is in any case to be noted that there is no intention to limit the invention to the specific embodiment illustrated, rather on the contrary, the invention intends covering all the modifications, alternative and equivalent constructions that fall within the scope of the invention as defined in the claims.

The use of "for example", "etc.", "or" indicates non-exclusive alternatives without limitation, unless otherwise indicated. The use of "includes" means "includes, but not limited to" unless otherwise stated.

With reference to the Figures, the management of one or more communications according to the Bluetooth standard by a software application installed on a primary electronic device - which will be indicated with the expression 'first device' 10 below - with a secondary electronic device - referred to by the expression 'second device' 20 below - implemented by a method in accordance with an embodiment of the present invention is now described.

With particular reference to Figure 1, the first device 10, for example a smartphone, comprises a processing module 11, a memory module 13, a Bluetooth communication module - which will be indicated with the expression 'BT module' 15 below - and a user interface 17.

The processing module 11 is configured to manage the operation of the entire first device 10. For this purpose, the processing module 11 can comprise one or more of a processing element - such as a processor, a microprocessor, a microcontroller, an ASIC, an FPGA, a DSP, etc. - and one or more ancillary circuits - such as a sync signal generation circuit (clock), ADC and/ or DAC converters, input/ output signal amplifiers, etc. Advantageously, the processing module 11 is configured to implement operating procedures, stored in the memory module 13, for example, in the form of software applications or in hardware components, for example, in the form of firmware.

The memory module 13 preferably comprises at least one non-volatile memory unit and at least one volatile memory unit configured to permanently and temporarily store data, respectively, typically in binary format.

The BT module 15 comprises the elements - such as antennas, control elements, coding elements, signal compression and decompression elements, mixers, etc. - that are necessary to transmit and receive data via a communication defined by the Bluetooth (BT) and/ or Bluetooth Low Energy (BLE) standard.

The interface module 17 comprises one or more input and output elements configured to provide information and/or receive instructions from a user of the first device 10, for example, one or more of a screen, a speaker, a microphone, a vibrator, an accelerometer, a magnetometer, a camera, a touch sensor, etc. In the example of Figure 2, the first device 10 comprises a touch screen 171.

The first device 10 can naturally comprise one or more additional modules (not illustrated) and ancillary circuitry for operatively connecting the various modules to each other. For example, in the case of a smartphone, a power supply module, one or more cellular communication modules (GSM, UMTS, LTE, etc.), a WiFi communication module, etc. are also generally provided.

Preferably, the processing module 11 is connected to the other modules 13, 15, 17 of the first device 10 to control the operation thereof.

The second device 20 comprises a processing module 21, a memory module 23 and a BT module 25 with functionalities similar to the corresponding modules 11, 13, 15 described above, with the processing module 21 connected to the remaining modules 23 and 25 to control the operation thereof. The second device 20 may also comprise one or more additional modules (not illustrated) - such as an interface module, a power supply module, etc. - and the necessary ancillary circuitry.

In particular, the first device 10 and the second device 20 are configured to establish a communication via the Bluetooth communication channel 40 to allow an exchange of information. This is typically referred to as pairing the devices in the jargon. In particular, the first device 10 is configured to establish a wireless communication channel - that is, based on transceiving electromagnetic signals - towards the second device 20, which can be exploited by several software applications and / or software services stored on one of the two devices.

At least the first device 10 is configured to execute an operating system or OS (acronym) referred to as 'native OS OS _\ ' in the following by exploiting the resources of the processing module 21 and of the memory module 23 of the first device 10 - in particular, Figure 4 schematically indicates the memory resources 130 used and/or controlled by the native OS OS _N - Advantageously, the native OS OS _N implements a graphic interface 31 or GUI (Graphic User Interface, schematically illustrated in Figure 2) with which a user can interact via the user interface 17 of the first device 10, preferably through the touch screen 171. In one embodiment of the present invention, the executed native OS OS _N is a version of the operating system called Android and developed by Google Inc.

The memory module 13 is configured to store and execute on demand one or more software applications A, A _B and A _CB - indicated with the term 'app' in the jargon. For example, a portion of non-volatile memory of the memory module 13 keeps a compressed data archive - APK (short for "Android Package") in the case of the Android OS - for each software application A, A _B and A _CB (represented by a solid line box in Figures 1 and 4).

In particular, one or more of said apps AB stored in the memory module 13 provide for the exchange of information according to the Bluetooth standard, i.e. they are enabled or configured to exchange data via a Bluetooth channel. Furthermore, a Bluetooth control app ACB is stored in the memory module 13 adapted to implement an embodiment of the present invention, as described below.

Through the graphic interface 31, the user can interact with one or more of the apps A, A _B and A _CB stored on the first device 10, which are typically represented by a corresponding icon 313 included in a main screen of the graphic interface 31 displayed on the touch screen 171 of the first device 10.

In general, when the user selects one of the apps A, A _B and A _CB the native OS OS _N is configured to allocate a volatile and/or non-volatile memory portion of the memory module 13 (represented by a dashed box in Figures 1 and 4) dedicated exclusively to the execution of the selected app A, A _B and A _CB by exploiting the allocated resources of the memory module 13.

In the example considered, the Bluetooth control app ACB can be executed by the user interacting with a corresponding icon 315 to implement a method 500 for managing the communication channel according to the Bluetooth protocol in accordance with an embodiment of the present invention.

With particular reference to Figure 3, the method 500 comprises the following steps.

Initially, a virtual environment VOS is created that is configured to allow the execution of one or more apps A _B in its inside (block 501). For example, the virtual environment VOS is created in a transparent manner to the user once the latter commands the execution of the Bluetooth control app A _CB .

In particular, when the Bluetooth control application ACB is started, the native OS OS _N below, allocates a dedicated memory area 131 - either volatile and/or non-volatile - of the resources of the memory module 13 (as schematically in Figure 1 and Figure 4), which is exclusively dedicated to the Bluetooth control app ACB from the operating system (block 5011 of the flowchart 501 illustrated in Figure 3).Inside this dedicated memory area 131, an instance of the Bluetooth control application ACB is created (block 5012). Once being executed, the Bluetooth control application ACB in turn instantiates the virtual environment VOS inside a sub-portion of the dedicated memory area 131 (block 5013).

In the embodiments of the present invention the created virtual environment VOS is a replica of the native OS OS _N - that is, the Android operating system in the example considered. In detail, the virtual environment VOS is configured to operate at the application layer in order to execute instances of one or more apps AB, which are configured to communicate via Bluetooth, according to a procedure substantially corresponding to that implemented by the native OS, that is, in such a way as to allow the execution of multiple applications, preserving the functionality thereof and guaranteeing access to all the services of the OS native OS _N , advantageously, via the Bluetooth control application A _CB which manages the interaction between app A _B and the native OS OS _N as illustrated below. In other words, the virtual environment VOS basically emulates the management of the software applications A, A _B executed by the native OS OSN-

In series (or in parallel), the apps A _B which are configured to communicate via Bluetooth stored in the memory module are identified (block 503).For this purpose, both the apps A, A _B already stored in the memory module 13 of the first device 10 at the time of a first execution of the Bluetooth control app A CB and each app A, A _B subsequently stored in the memory module 13 are advantageously analysed.

For each app A _B configured to communicate via Bluetooth it is asked to the user whether he wishes that said app A _B is executed inside the virtual environment VOS (block 505).For example, an interactive message is displayed on the touch screen 171 to offer the user the possibility to select between executing the app A _B in a 'normal' mode or executing the app A _B in 'secure mode' - that is, inside the virtual environment VOS.

The choices made by the user are thus stored (block 507).For example, a list of the apps A _B selected by the user for executing in secure mode are stored in a non-volatile memory portion of the memory module 13 allocated for executing the Bluetooth control app A _CB .

Subsequently, the status of the apps A _B selected for the execution in secure mode is monitored (decision block 509). In particular, execution commands of such apps A _B are identified.

Until a command to execute an app A _B , configured to communicate via Bluetooth (output branch N of block 509) is detected, no action is taken. Preferably, the method 500 comprises monitoring both manual execution commands provided by the user and execution commands generated by other applications in a manner transparent to the user.

When a command to execute one of these selected apps A _B is identified (output branch Y of block 509), an instance of said app A _B is created inside the previously created virtual environment VOS.

For example, the Bluetooth control application A _CB is configured to load the compiled code of the app A _B present in the corresponding compressed data archive (APK) and execute it by means of the virtual environment VOS.

Thanks to said configuration, a generic app A _B being executed in the virtual environment VOS is isolated from the native OS OS _N -AS a result, the generic app A _B being executed in the virtual environment VOS is unable to directly make function calls to the native OS OS _N , to the other apps A stored and/ or instantiated by the native OS OS _N - allocating a respective portion of memory resources to each of which, like the portion of memory resources 132 allocated for the application A in Figure 4 - is able to directly access portions of memory (not illustrated) that are external to the dedicated memory area 131 in which the virtual environment VOS is implemented. Similarly, each of the apps A instantiated directly from the native OS OS _N is unable to interact with any of the apps A _B being executed in the virtual environment VOS.

Each app A _B instantiated by the virtual environment VOS is monitored in order to identify an attempt to communicate with the second device 20 coupled to the first device 10 via the Bluetooth channel 40 (decision block 511).

Advantageously, the Bluetooth control app A _CB is configured to detect any system calls executed by the app A _B instantiated in the virtual environment VOS and directed to the native OS OS _N , and to identify each system call that plans to exploit a Bluetooth connection.

Until an attempt to communicate with the second device 20 by an app A _B configured to communicate via Bluetooth (output branch N of block 511) is detected, no action is taken.

For example, if system calls are detected that do not exploit a Bluetooth communication channel, the Bluetooth control app A _CB is configured to liaise - or 'proxy' - between the app A _B instantiated by the virtual environment VOS and the native OS OS _N - In other words, the Bluetooth control app A _CB is configured to intercept system calls executed by the app A _B instantiated by the virtual environment VOS and respective responses provided by the native OS OS _N , if necessary, appropriately adapting the parameters thereof.

Conversely, when an attempt to communicate with the second device 20 by an app A _B configured to communicate via Bluetooth (output branch Y of block 511) is detected, said communication is blocked and the user is asked if he wishes to allow said app A _B to exchange data with the second device 20 (decision block 513). For example, the Bluetooth control app A _CB is configured to intercept system calls that envisage the use of a Bluetooth communication channel executed by the app A _B , instantiated by the virtual environment VOS, to suspend the routing of the same to the native OS OS _N -

At the same time, an interactive message is displayed on the touch screen 171 to offer the user the possibility of selecting either to allow or prevent the app A _B instantiated in the virtual environment VOS from exchanging data with the second device 20. For example, the Bluetooth control app A _CB is configured to generate one or more calls to the native OS _N in order to present the interactive message mentioned above, when a first system call is detected that comprises the use of a Bluetooth communication channel executed by the app A _B instantiated in the virtual environment VOS. Preferably, albeit not limitatively, it is envisaged that identification information of the second device 20 with which the app A _B attempts to communicate via Bluetooth is provided - for example, it is possible to identify a model, type and/ or identification code of the second device 20 - via the interactive message.

In case the user chooses to allow the app A _B to exchange data with the second device 20 (output branch Y of block 513), said app A _B is allowed to establish a communication with the second device 20 via the Bluetooth communication channel 40 (block 515). For example, the Bluetooth control app A _CB is configured to route to the native OS _N system calls that envisage the use of a previously blocked Bluetooth communication channel and the return to the app A _B instantiated in the virtual environment VOS of the responses provided by the native OS _N - i.e. by operating as a proxy as described above.

In case the user chooses not to allow the app A _B to exchange data with the second device 20 (output branch N of block 513), then any attempt by said app A _B to establish a communication with the second device 20 is blocked (block 517). For example, the Bluetooth control app A _CB is configured to permanently block any system call that comprises the use of a Bluetooth communication channel executed by the app A _B , instantiated in the virtual environment VOS.

Regardless of the selection made in block 513, the method 500 comprises continuing to monitor the operation of the apps A _B being executed inside the virtual environment VOS as described above starting from block 511.

The invention thus conceived is susceptible to several modifications and variations, all falling within the scope of the inventive concept.

For example, it is possible to envisage storing the choices made by the user in relation to each app A _B in step 513 so as to automate the execution of the method 500 according to the user's preferences.

In other variations of the method (not illustrated), it can be envisaged that all the apps A _B which are configured to communicate via Bluetooth identified on the first device 10 are automatically selected for the execution in secure mode, i.e. they are always executed inside the virtual environment VOS.

It is certainly possible to envisage embodiments which allow the user to modify the list of the apps A _B configured to communicate via selected Bluetooths for being executed inside the virtual environment VOS.

Furthermore, it is possible to envisage the execution of the Bluetooth control app A _CB automatically, for example when the first device 10 is switched on.

In an alternative embodiment illustrated in Figure 4, the alternative method 500a comprises defining, for each app AB - preferably, among those selected for the execution inside the virtual environment VOS as described in block 505 - one or more second devices 20 with which communication via a corresponding Bluetooth communication channel 40 is allowed (block 519).

Advantageously, when an attempt to communicate with the second device 20 coupled to the first device 10 via the Bluetooth channel 40 (at the decision block 511) is identified, the alternative method 500a comprises blocking the communication and verifying if the second device 20 is included between the one or more second devices 20 defined in the previous block 519 (decision block 521).

In the affirmative case (output branch Y of block 521) the communication via Bluetooth is directly allowed (as described above in relation to block 515).

Conversely, if the second device 20 does not correspond to the one or more second devices 20 defined in the previous block 519 (output branch N of block 521) the user is asked whether he wishes to allow said app AB to exchange data with the second device 20 (as described above with reference to decision block 513).

Alternatively, it is possible to automatically block all the attempts to communicate via Bluetooth directed towards a second device 20 not associated with the app AB which executes said attempt to communicate via Bluetooth.

Also in this case it is thus possible to define in advance if a user give consent or not to the communication between an app A _B and the second device 20.

Obviously, although the examples described above refer to a first device 10 coupled to a single second device 20, the control of the communications via Bluetooth according to the embodiments of the present invention is applicable without requiring substantial modifications in case the first device 10 is coupled simultaneously with two or more second devices 20.

Moreover, all the details can be replaced by other technically equivalent elements. In particular, one or more steps of the methods described above can be carried out in parallel with each other rather than in series. Furthermore, nothing prevents from combining the steps of two or more of the methods 500 and/ or 500a to obtain a combined method, as well as one or more optional steps of the methods described above can be added and/ or removed according to the specific implementation needs without thereby falling outside the relative scope of protection, as defined by the appended claims.