WO2025159669A1

WO2025159669A1 - Methods and apparatuses for handling private data in a secure environment

Info

Publication number: WO2025159669A1
Application number: PCT/SE2024/050061
Authority: WO
Inventors: Lina PÅLSSON; Niklas LINDSKOG; Patrik Salmela; Håkan ENGLUND; Tommy Arngren
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-01-24
Filing date: 2024-01-24
Publication date: 2025-07-31
Anticipated expiration: 2026-07-24

Abstract

Embodiments of the present disclosure provide a method (600) performed by a computing device (108) for data sharing in a secure environment (106). The computing device is in communication with a second device (104) configured to be accessed by a first device (102) for at least one time instance. The method comprises receiving, from the second device, a first request for private data. The method comprises determining whether the second device is equipped with a session identifier, ID, of the first device. When it has been determined that the second device is equipped with the session ID, the method comprises transmitting the requested private data to the second device via a secure channel. The private data comprising at least a part of profile data of the first device and being adapted for performing at least one task associated with the first device on the second device.

Description

METHODS AND APPARATUSES FOR HANDLING PRIVATE DATA IN A SECURE ENVIRONMENT

TECHNICAL FIELD

The present disclosure relates to field of cloud security systems. More particularly, it relates to methods, computing device, first device, second device, and computer program product for handling private data in a secure environment.

BACKGROUND

Borrowing or lending applications are gaining more importance nowadays. The borrowing or lending applications enable a user to borrow or utilize a device from a pool of identical or similar devices (hereinafter referred to as lending devices) for occasionally/temporarily/at least one time instance. The pool can have a common owner like a company or a community. In some examples, the pool can comprise identical or similar lending devices, but the owner is not common for all the devices. Examples of the lending devices may include a screen, Virtual Reality, VR, Extended Reality, XR, or Augmented Reality, AR, devices, a vehicle, a medical test equipment, a machine, or the like. Examples of the owner may include a renting company, a sharing pool owner, a private person, or a company.

The user can utilize the lending device to perform one or more tasks using suitable applications such as, screens, camera, microphone, speakers, or the like. In order to initiate/perform the one or more tasks, the lending device may require profile data of the user or a user device being used by the user and/or profile data of the owner operating the respective lending device. The profile data of the user/user device can include sensitive data like personal data, preferences, medical related details, or the like. Thus, the user does not want the profile data to be leaked, nor be freely accessible to the owner of the lending device nor to the other borrowers/users. Similarly, the profile data of the owner can include sensitive data like application data and application settings for the lending device. Hereinafter, the profile data of the user/user device and the profile data of the owner are collectively referred to as private data. Further, with an increase in the number of lending devices in the pool, the private data needs to be available for all of the lending devices. Consider an example scenario, wherein the user lends a first car (an example of the lending device) from a car pool for a first time instance, and the user lends an identical second car from the car pool for a second time instance. In such a scenario, the private data utilized/created to perform the one or more tasks on the first car should be available also in the second car. Thus, the lending applications require effective storage and handling of the private data.

In some examples, the private data can be stored in a centralized server implementing the lending application, so that the private data may be stored persistently externally rather than inside of each lending device. The centralized server may provide the volatile private data to the lending devices while performing relevant one or more tasks.

In some examples, the user device and/or the centralized server can store the private data and shares the private data with the lending device after authentication. Such a solution can work in some cases and can be particularly useful in scenarios where the lending device does not have Internet access. Consider an example scenario, wherein the user may decide to lend or rent a kick-bike/bicycle from a pool of kick-bikes/bicycles provided by "abc" services via "abc.com". In such a scenario, lending/renting the kick-bike requires the user to register via the user device to the "abc" services and to install an application operative in said user device. After registering, a first part of the private data may be stored in the user device and a second part of the private data, possibly overlapping with the first part, may be stored in the centralized server implementing a lending application related to the "abc" services. The user data and the centralized server may provide the respectively stored private data to the lending device while the one or more tasks of the user are performed on any other second device.

SUMMARY

It is important to effectively store and handle the private data in order to enable the owners (the user and/or the owner operating the lending devices) to control ownership of their private data. However, the private data may in the future in several cases become more advanced, e.g., in terms of complexity and granularity, than today, which may increase a need of a common and capable storage solution for such data.

Further, collecting and storing the private data is a commonly known problem, as the private data may leave sensitive data vulnerable to unauthorized access, theft, and misuse. The stored private data can be used for Machine Learning based algorithm developments and generating statistics. However, there can also be a usage directly connected to the user, like selling the private data for personalized advertisement. The user may not have control over what data is collected and how, where and for what the collected data is used.

Furthermore, with an increase in connecting a number of lending devices with the user devices, storing the private data locally on the user devices may not be desirable and/or possible due to need of more advanced settings. Further, the lending devices like vehicles and VR/AR devices use offloading for capacity as well as for central evaluation like statistics and machine learning based models.

Furthermore, storing the private data both in the user device and the central server makes it difficult to have transparency related to who accesses the private data.

Furthermore, different lending services/applications may not easily share anonymous usage data between each other, as there is no common database for such a purpose.

In addition, the private data may be both sensitive and consume a lot of storage space. In some examples, the private data may include video or massive sensor reading collections that can be utilized by machine learning models in the user device. In some examples, the private data may include application data needed with stored application settings. In such a scenario, the application data may be used for multiple different applications might need to utilize in different ways and/or for different purposes. Thus, if the application data needs to be stored per application, it may result in duplicated data being stored, which may be an issue for large data sets.

Thus, there may be no solution to let the owner in control of their private data, which made the owner/user has to fully and blindly trust a device lending company providing the lending applications to handle and store their private data in an acceptable way. Further, in some situations the user may not have full access to the data related to them since the data in some cases may be mixed up with the data owned by owner of the device, not to be shared with the user.

Consequently, there is a need for an improved method and arrangement for handling private data in a secure environment, which alleviates at least some of the above-cited problems.

It is therefore an object of the present disclosure to provide methods, a computing device, a first device, a second device, and a computer program product for handling private data in a secure environment, to mitigate, alleviate, or eliminate all or at least some of the abovediscussed drawbacks of presently known solutions.

This and other objects are achieved by means of methods, a computing device, a first device, a second device, and a computer program product as defined in the appended claims. The term exemplary is in the present context to be understood as serving as an instance, example or illustration.

According to a first aspect of the present disclosure, a method performed by a computing device for data sharing in a secure environment is provided. The computing device is in communication with a second device. The second device is configured to be accessed by a first device for at least one time instance. The method comprises performing a handshake with the second device to establish a secure channel between the second device and the computing device. The method comprises receiving from the second device via the established secure channel, a first request for private data. Upon receiving the first request, the method comprises determining whether the second device is equipped with a session identifier, ID, of the first device. When it has been determined that the second device is equipped with the session ID of the first device, the method comprises transmitting the requested private data to the second device via the established secure channel. The private data comprises at least a part of profile data of the first device and is adapted for performing at least one task associated with the first device on the second device.

In some embodiments, the method comprises uploading, through at least one of the first device or the second device, at least one configuration data into the second device or the first device, wherein the configuration data comprises the private data configured in the first device through at least one of the user of the first device, the second device or user of the second device.

In some embodiments, the method comprises receiving, from the second device via the secure channel established between the second device and the computing device, at least one of: newly created or modified private data on the second device while the at least one task associated with the first device is performed on the second device, wherein at least one of: newly created or modified private data on the second device is identified according to an update in a key-value data shared through the second device, wherein the key represents an update in the private data and the value represents the private data.

In some embodiments, the method comprises requesting the second device to remove the private data, upon expiration of the session ID of the first device equipped by the second device.

In some embodiments, the method comprises monitoring information related to the first device while the at least one task associated with the first device is performed on the second device. The method comprises monitoring, via a log and analyse instance, information related to the second device while the at least one task associated with the first device is performed on the second device. Based on evaluation of the monitored information related to the first device and the second device, the method comprises determining whether the first device or the second device is performing any unauthorized action. When it has been determined that the first device or the second device is performing any unauthorized action, the method comprises performing one or more data handling actions to prevent the first device or the second device from performing any unauthorized action.

In some embodiments, the information related to the first device identifies at least one of: an amount of private data accessed from the second device and whether the at least one task is from the one or more tasks is the task requested by the first device and is to be performed on the second device. In some embodiments, the information related to the second device identifies at least one of: an amount of private data and a type of data requested or used by the second device and a frequency associated with generation of requests from the second device for the private data. In some embodiments, the unauthorized action comprises at least one of: requesting for the private data that is not relevant for the at least one task of the first device, requesting the private data for performing the at least one task that is unauthorized to perform on the second device and requesting for performing the at least one task manipulating the private data that is unauthorized to perform on the second device. The at least one task is performed on the second device.

In some embodiments, the step of performing the one or more data handling actions comprises one or more of: terminating transmission of the private data to the second device, transmitting an indication to the second device to terminate the at least one task being performed on the second device, and transmitting an indication to the second device or the first device to disconnect a session established between the second device and the first device.

In some embodiments, the method further comprises receiving the profile data of the first device and storing the profile data in a database or a data source among a plurality of data sources. The data source is dedicated for the first device. The method comprises communicating the session ID to the first device, wherein the session ID is shared between the first device and the second device and used to determine whether the first device is an authenticated and authorized device to access the second device, wherein the session ID is temporary session ID used to identify an access of the private data allowed to the second device.

In some embodiments, the step of receiving the profile data of the first device comprises performing a handshake with the first device to establish a secure channel between the first device and the computing device and receiving, from the first device, the profile data via the secure channel established between the first device and the computing device.

In some embodiments, the step of receiving the profile data of the first device comprises receiving the profile data of the first device through the second device, when the first device is configured to communicate with the computing device through the second device.

In some embodiments, the step of transmitting the requested private data to the second device comprises identifying the at least one task to be performed on the second device, wherein the at least one task is associated with the first device. The method comprises determining whether the requested private data is relevant for performing the identified at least one task on the second device. When it has been determined that the requested private data is relevant for performing the at least one task, the method comprises verifying whether the second device is an authenticated and authorized device to receive the requested private data. Upon verifying that the second device is the authenticated and authorized device, the method comprises transmitting the requested private data to the second device.

In some embodiments, the step of transmitting the requested private data to the second device further comprises identifying the first device for which the private data is requested from the second device. The method comprises fetching the requested private data associated with the identified first device from the database or the data source dedicated for the identified first device. The method comprises transmitting the requested private data to the second device.

In some embodiments, the step of transmitting the requested private data to the second device further comprises dividing the requested private data into a plurality of data chunks based on the at least one task to be performed on the second device. The method comprises transmitting the plurality of data chunks to the second device sequentially, while the at least one task being performed on the second device.

In some embodiments, the step of requesting the second device to remove the transmitted private data comprises receiving, from at least one of: the second device and the first device, a second request indicating an expiry of the session ID of the first device equipped by the second device. The method comprises requesting the second device to remove the transmitted private data upon receiving the second request and receiving, from the second device, an optionally signed confirmation of the removal of the private data.

In some embodiments, the method further comprises receiving a termination message from the second device. The termination message indicating that the second device has removed the transmitted private data and indicating to terminate a communication session between the second device and the computing device.

In some embodiments, the first request received from the second device indicates at least one of: a device for which the private data is requested, an amount of private data, and a type of private data. In some embodiments, the private data comprises a profile data of at least one entity operating the second device along with at least the part of the profile data of the first device.

In some embodiments, the session ID comprises at least one of: a permanent identifier, a temporary identifier, a token, and a key assigned by the computing device for the first device to establish a communication session with the second device. The session ID comprises an anonymous and temporary ID of the first device allocated for each session between the computing device and the second device, and wherein the session ID comprise an ID of the second device shared with the first device and comprise a scan QR code on the second device shared with the computing device, either as part of authentication to get token, or as a trigger for the computing device to provide the private data to the second device. According to a second aspect of the present disclosure, a method performed by a second device for data access in a secure environment is provided. The second device is in communication with a computing device in the secure environment and accessed by a first device for at least one time instance. The method comprises performing a handshake with the computing device to establish a secure channel between the second device and the computing device. The method comprises transmitting, to the computing device via the established secure channel, a first request for private data. The private data comprising at least a part of profile data of the first device. The method comprises receiving, from the computing device via the established secure channel, the requested private data, when the second device is equipped with a session identifier, ID, of the first device. The method comprises initiating at least one task associated with the first device using the received private data.

According to a third aspect of the present disclosure, a method performed by a first device for accessing a second device in a secure environment for at least one time instance is provided. The second device is in communication with a computing device in the secure environment. The method comprises sharing a session identifier, ID, with the second device. The method comprises requesting, based on the shared session ID, the second device to initiate at least one task to be performed on the second device. The at least one task is performed based on reception of private data from the computing device. The private data comprises at least a part of profile data of the first device.

According to a fourth aspect of the present disclosure, a computing device for data sharing in a secure environment is provided. The computing device is in communication with a second device. The second device is configured to be accessed by a first device for at least one time instance. The computing device is adapted for performing a handshake with the second device to establish a secure channel between the second device and the computing device. The computing device is adapted for receiving, from the second device via the established secure channel, a first request for private data. Upon receiving the first request, the computing device is adapted for determining whether the second device is equipped with a session identifier, ID, of the first device. When it has been determined that the second device is equipped with the session ID of the first device, the computing device is adapted for transmitting the requested private data to the second device via the established secure channel. The private comprises at least a part of profile data of the first device and is adapted for performing at least one task associated with the first device on the second device.

According to a fifth aspect of the present disclosure, a second device adapted for data access in a secure environment is provided. The second device is in communication with a computing device in the secure environment and accessed by a first device for at least one time instance. The second device is adapted for performing a handshake with the computing device to establish a secure channel between the second device and the computing device. The second device is adapted for transmitting, to the computing device via the established secure channel, a first request for private data. The private data comprising at least a part of profile data of the first device. The second device is adapted for receiving, from the computing device via the established secure channel, the requested private data, when the second device is equipped with a session identifier, ID, of the first device. The second device is adapted for initiating at least one task associated with the first device using the received private data.

According to a sixth aspect of the present disclosure, a first device adapted for accessing a second device in a secure environment for at least one time instance is provided. The second device is in communication with a computing device in the secure environment. The first device is adapted for sharing a session identifier, ID, with the second device. The first device is adapted for requesting, based on the shared session ID, the second device to initiate at least one task to be performed on the second device. The at least one task is performed based on reception of private data from the computing device. The private data comprises at least a part of profile data of the first device. According to a seventh aspect of the present disclosure, a data handling system for handling private data in a secure environment is provided. The data handling system comprises a computing device, a first device, and a second device according to fourth, sixth, and fifth aspects of the present disclosure, respectively.

According to an eight aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions. The computer program is loadable into a data processing unit and configured to cause execution of the method according to the first aspect when the computer program is run by the data processing unit.

In some embodiments, any of the above aspects may additionally have features identical with or corresponding to any of the various features as explained above for any of the other aspects.

An advantage of some embodiments is that alternative and/or improved approaches are provided for securely and efficiently storing and sharing the private data with instances of the second device only when it is needed. As a result, trustworthiness may be provided in how and where the profile/private data of the first device is used while lending/accessing the second device by the first device for at least one time instance.

An advantage of some embodiments is that the private data may be shared with the second device without exposing the private data to untrusted devices.

An advantage of some embodiments is that exposure of the private data towards the second device and the first device may be minimized. Thus, privacy of the private data may be increased.

An advantage of some embodiments is that the private data may be stored in the computing device for long term, as the computing device is deployed in the secure environment, which may be attested by, or on behalf of the first device.

An advantage of some embodiments is that the computing device may compile trustworthy summaries of the second device's information fetching for the private data. An advantage of some embodiments is that a user of the first device may be allowed to keep control of their profile/private data while accessing the second device, so that the user may be convinced that the private data may be handled fairly.

Further, the proposed methods may be used in future scenarios where the private data may be advanced, extensive, and dynamic.

Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

Figs. 1A and IB disclose a data handling system according to some examples;

Figs. 2A and 2B are schematic block diagrams illustrating an example computing device in a data handling system;

Fig. 3 is a signaling diagram illustrating example signaling;

Fig. 4 is a signaling diagram illustrating example signaling;

Fig. 5 is a signaling diagram illustrating example signaling;

Fig. 6 is a flowchart illustrating method steps performed at a computing device according to some examples;

Fig. 7 is a flowchart illustrating method steps performed at a second device according to some examples;

Fig. 8 is a flowchart illustrating method steps performed at a first device accordingto some examples; Fig. 9 is a schematic block diagram illustrating functional modules of a data-sharing manager in a computing device according to some examples;

Fig. 10 is a schematic block diagram illustrating an example second device;

Fig. 11 is a schematic block diagram illustrating an example first device; and

Fig. 12 discloses an example computing environment.

DETAILED DESCRIPTION

Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The apparatus and method disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

The terminology used herein is for the purpose of describing particular aspects of the disclosure only and is not intended to limit the invention. It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof.

In general, lending applications/services allow a user to use a device from a pool of identical or similar devices (referred hereinafter as lending devices) for occasionally/temporarily/at least one time instance to perform one or more tasks. The lending device may require private data to initiate or perform the one or more tasks requested by the user. The private data herein may include profile data of the user and/or profile data of an entity/owner operating the lending device. Further, the private data can include sensitive data, thereby the user or the owner operating the lending device wants to control the respective private data.

In some examples, the private data may include application settings and application data, which may be extensive, and may incorporate Machine Learning, ML, models. In such a scenario, the ML models may be executed in a common, cloud based, and trustworthy location. Other tasks for such a common trustworthy location may be collecting, storing and processing data from different lending devices of the pool. Furthermore, some of the private data can be provided by the user to the lending device or some of the private data can also be created or updated in the lending device during the utilization. However, independent of the origin, the private data can be sensitive.

In some examples, the private data may be stored in a user device (being used by the user) and/or central server providing the lending application. The user device or the central server may provide the private data to the lending device upon successful authentication. Such a solution may not be user-controlled solution, as it is difficult to have transparency related to who access the private data of the user. Thus, the user has to blindly trust a lending company providing the lending application to handle and store their private data in an acceptable way.

Therefore, a data handling system is provided herein for secure and effective storage and handling of private data in a trustworthy location.

Figs. 1A and IB disclose an example data handling system 100. The data handling system 100 referred herein is adapted for secure data storage and sharing in a secure environment 106. The data handling system 100 comprises one or more first devices 102, one or more second devices 104, and a computing device 108.

In an example, the data handling system 100 may comprise the user directly allowed to access the second device 104 based on an identification of the user with the second device 104 through at least one of a password or biometrics authorising the user for the access of the private data in the second device 104.

The first device 102 referred herein may be a user device being used by a user to access at least one of the second devices 104 for at least one time instance (i.e., for temporarily or occasionally). That is the first device 102 may temporarily use capabilities/resources of the second device 104. The term "first device" may be used interchangeably with "user device", "main device", or the like.

In some examples as depicted in Fig. 1A, the first device 102 may have communication and processing capabilities that enable the first device 102 to communicate with the second device(s) 104 and the computing device 108. In some examples, the first device 102 may act as a standalone device with a FIDO2 capable token. Examples of the first device 102 may include, but are not limited to, smart phones, mobile phones, cell phones, voice over IP, VoIP, phones, wireless local loop phones, desktop computers, personal digital assistants, PDAs, wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop-embedded equipment, LEE, laptop-mounted equipment, LME, smart devices, wireless customer-premise equipment, CPE, mobile-type communication, MTC, devices, Universal Serial Bus, USB, dongles, I nternet-of -Things, loT, devices, vehicle-mounted wireless terminal devices, D2D UEs, V2X UEs, a Radio Frequency Identification. RFID, tag, and so on. In some examples, the first device 102 may be used in combination with or as integrated part of a handheld device or a wearable device.

In some examples as depicted in Fig. IB, the first device 102 may have limited communication and processing capabilities, so that the first device 102 may communicate with the computing device 108 through the second device 104. In such a scenario, the first device 102 may include, but are not limited to, a user tag, UT, i.e., a constrained device identifying the user, an Input/Output device, IOD, i.e., a device which can provide input and/or output capabilities for a session, a payment card (for example, debit or credit card), and so on.

The first device 102 may communicate with the second device 104 and/or the computing device using a communication network (not shown in Figs. 1A and IB). The communication network may implement communication standards, such as, but are not limited to, global system for mobile communications, GSM, universal mobile telecommunications system, UMTS, long term evolution, LTE, and/or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network, WLAN, standards such as, IEEE 802.11 standards, and/or any other appropriate wireless communication standards, such as, worldwide interoperability for microwave access, WiMax, Bluetooth, Z-Wave and/or ZigBee standards and/or any physically connected device or wired devices.

The second devices 104 referred herein may be devices used/accessed by the first device 102 for the at least one time instance. The term "second device" may be used interchangeably with "lending device", "peripheral device", "temporary device", or the like. Examples of the second device 104 may include, but are not limited to, a screen, a Virtual Reality, VR, Extended Reality, XR, or Augmented Reality, AR, devices, a XR headset, an loT device, a vehicle, a medical test equipment, a robot, a machine, and so on. The second devices 104 may form a pool of identical or similar devices. In some examples, the pool may have a common owner. In some examples, the pool may not have a common owner. Examples of the owner may include, but are not limited to, a renting/lending company, a community, an individual user, and so on.

The second devices 104 are configured to be in communication with the computing device 108 using the communication network.

The computing device 108 may be a cloud based, trustworthy, and remotely attestable entity deployed in the secure environment 106. Examples of the secure environment 106 may include, but are not limited to, Trusted Execution Environment, TEE, protected environment, a Cloud Based Trustworthy Environment, CBTE, and so on. Examples of the computing devices 108 may include, but are not limited to, a server, a multi-processor system, a microprocessorbased or programmable consumer electronic device, a network computing device, a cellular phone, a personal digital assistant, PDA, a handheld device, a laptop computer, or a combination thereof.

In some examples, the computing device 108 and the second device 104 may be equipped with TEE, which may be remotely attestable according to known protocols like IETF Remote Attestation Procedures, RATS. If more than one TEE is used, then attestation chains may be created for remote attestation of the computing device 108 orthe second device 104. In some examples, the used software may not be fully executed within the TEE, however a hardware module of the second device 104 like a TEE or a Trusted Platform Module, TPM, may be used as a hardware root of trust in the attestation of the second device 104. In other cases the device is not equipped with a TEE but a software solution, potentially including functionality erasing data when requested, e.g. erasing data when rebooting the device is implemented.

The computing device 108 may provide a lending application (also be referred to as renting application, borrowing application, or the like). The first device 102/user of the first device 102 may use the lending application to utilize/lend one of the second devices 104 for the at least one time instance to perform one or more tasks. The one or more tasks referred herein may be performed using applications being executed on the second device 104 such as, but are not limited to, a camera, a microphone, a speaker, a display application, a streaming application, a navigation application, a gaming application, and so on. Alternatively, the one or more tasks may be performed using computing resources of the second device 104. It should be understood that the tasks may be performed depending on the second device 104. For example, if the second device 104 is a screen, the first device 102 may utilize the screen to render media (audio, video, graphics, animations, or the like). For another example, if the second device 104 is an XR device, the first device 102 may utilize the XR device to playgames. For another example, if the second device 104 is a medical test equipment, the medical test equipment may be used to capture health parameters of the user.

Further, private data may be required to perform the one or more tasks associated with the first device 102 on the second device 104. In some examples, the private data may include profile data of the first device 102 (or the user of the first device 102). In some examples, the private data may include profile data of the first device 102 and profile data of an entity/owner operating the second device 104. Examples of the profile data of the first device 102 may include, but are not limited to, configurations and application data of the first device 102, physical traits, and personal preferences of the user associated with the first device 102, expected usage patterns of the first device 102 by the respective user, historical usage patterns of the second devices 104 by the user through the first device 102 (for example, the tasks performed on the second devices 104), or the like. Examples of the profile data of the entity associated with the second device 104 may include, but are not limited to, application settings for applications being executed on the second device(s) 104, credentials to be used for executing the applications on the second device 104, and so on. Thus, the private data referred herein may be sensitive data.

Therefore, the computing device 108 herein implements a method for secure and effective data sharing with the second device 104, when the first device 102 initiates accessing the second device 104 for the at least one time instance.

The computing device 108 performs a handshake with the second device 104 to establish a secure channel between the second device 104 and the computing device 108. The computing device 108 further receives a request from the second device 104 via the secure channel. Upon receiving the first request, the computing device 108 determines whether the second device 104 is equipped with a session identifier, ID, of the first device 102. When it has been determined that the second device 104 is equipped with the session ID of the first device 102, the computing device 108 transmits the requested private data to the second device 104 via the established secure channel. The private data comprises at least a part of the profile data of the first device 102 and is adapted for performing at least one task associated with the first device 102 on the second device 104.

In an example, the session ID is an anonymous and temporary ID of the first device 102 allocated for each session between the computing device 108 and the second device 104. In another example, the session ID may also comprise an ID of the second device 104 shared with the first device 102 and may comprise a scan QR code on the second device 104 which is shared with the computing device 108, either as part of authentication to get token, or as a trigger for the computing device 108 to provide the private data to the second device 104.

Various examples for private data handling in the secure environment 106 are explained in conjunction with figures in the later parts of the description.

Figs. 2A and 2B disclose example implementation of the computing device 108 for data sharing in a secure environment 106. The secure environment 106 may include, but is not limited to, Trusted Execution Environment, TEE, protected environment, a Cloud Based Trustworthy Environment, CBTE, or the like. The computing device 108 is configured to be in communication with a pool of second devices. A second device is accessed by a first device for at least one time instance/occasionally.

As depicted in Figs. 2A and 2B, the computing device 108 comprises a kernel 208 of an operating system, OS. The kernel 208 may be adapted for executing multiple application instances, for example, but are not limited to, an authentication service instance, an authorization service instance, and an attestation service instance (described in Fig. 5). The computing device 108 also comprises an underlying hardware. The hardware may comprise a Central Processing Unit, CPU 202, a memory 204, and a driver 206. The computing device 108 also comprises a data-sharing manager 250. The data-sharing manager 250 referred herein may be a controlling circuitry, which is adapted for controlling all the components 202-208 of the computing device 108. The data-sharing manager 250 is also adapted for handling data storage and data sharing in the secure environment 106.

In some examples, as depicted in Fig. 2A, the data-sharing manager 250 may be in communication with a database 260. The database 260 may store private data. In some examples, the private data may comprise profile data of the first device. In some examples, the private data may comprise the profile data of the first device and profile data of an entity/owner operating the second device 104. Examples of the profile data of the first device may include, but are not limited to, configurations and application data of the first device, physical traits, and personal preferences of the user associated with the first device, expected usage patterns of the first device by the respective user, historical usage patterns of the second devices by the user through the first device (for example, the tasks performed on the second devices), or the like. Examples of the profile data of the owner associated with the second device may include, but are not limited to, application settings for applications being executed on the second device(s), credentials to be used for executing the applications on the second device, and so on. Thus, the private data referred herein may comprise sensitive data originating from the first device/user of the first device as well as from the owner associated with the second device. That is the first device may also not have a free access to the private data.

In some examples, the data-sharing manager 250 may receive the profile data of the first device, when the first device registers with the data-sharing manager 250 of the computing device 108 for a first time to access the second device. In some examples, the data-sharing manager 250 may receive the profile data of the first device, prior to the first device deciding to access the second device. In some examples, the data-sharing manager 250 may also receive the profile data/additional profile data from the first device, while the first device is accessing the second device.

For receiving the profile data from the first device, the data-sharing manager 250 may perform a handshake with the first device to establish a secure channel between the first device and the computing device 108. The handshake may be performed for a mutual attestation between the first device and the computing device 108. In some examples, the handshake may be performed based on one of suitable IETF RATS protocols. Upon successful mutual attestation, the data-sharing manager 250 may receive the profile data from the first device via the secure channel established between the first device and the computing device. Thereby, the profile data may not be leaked to untrusted entities. In some examples, the data- sharing manager 250 may receive the profile data of the first device through the second device, when the first device is configured to communicate with the computing device 108 through the second device 104.

Further, the data-sharing manager 250 may receive the profile data of the owner/entity associated with the second device, when said owner registers the second device with the computing device 108. In some examples, the data-sharing manager 250 may receive the profile data of the owner from a device different from the second device. In some examples, the data-sharing manager 250 may receive the profile data of the owner from the second device itself. The data-sharing manager 250 may store the profile data of the first device and/or the profile data of the owner as the private data in the database 260.

In some examples, as depicted in Fig. 2B, the data-sharing manager 250 may be in communication with one or more data sources 270a-270n dedicated for respective one or more first devices. In such a scenario, when the data-sharing manager 250 receives the profile data of the first device, the data-sharing manager 250 may identify a data source dedicated for the first device and may store the profile data of the first device in the identified data source. In some examples, the data-sharing manager 250 may store the profile data of the entity(ies) operating the second device(s) in all the data sources 270a-270n. In some examples, the data-sharing manager 250 may store the profile data of the owner/entity operating the second device in the database 260.

It should be understood that the data-sharing manager 250 may receive the private data before the first device deciding to access the second device or when the first device initiates accessing the second device. Also, the data-sharing manager 250 may request the first device and/or the owner/entity associated with the second device for additional private data, during accessing of the second device by the first device.

Upon storing the private data, the data-sharing manager 250 may communicate session identifier, ID to the first device. The session ID may be shared between the first device and the second device to determine whether the first device is an authenticated and authorized device to access the second device. The session ID may comprise at least one of: a temporary identifier, a token, and a key assigned for the first device to establish a communication session with the second device. It should be noted that the session ID may not reveal an original identity of the first device and the session ID may be derived based on other privacy enhancing technologies such as zero-knowledge proofs.

In some examples, the session ID may act as an access token. The access token may also indicate what private data may be accessed by the second device. The data-sharing manager 250 may decide what private data has to be accessed by the second device.

In some examples, the data-sharing manager 250 may decide how to use the private data stored in the database 260 or the data sources 270a-270n. For instance, for trustworthy use of the private data, the data-sharing manager 250 may decide to enable or disable usage of the private data for anonymized statistics or machine learning based model developments. In such a scenario, the computing device 108 may act as a data clean room.

The data-sharing manager 250 is further adapted for sharing the private data with the second device in the secure environment 106.

For sharing the private data, the data-sharing manager 250 performs a handshake with the second device to establish a secure channel between the computing device 108 and the second device. The handshake referred herein may be for a mutual attestation between the computing device and the second device. In some example, the handshake/mutual attestation may be performed according to known protocols like IETF RATS. It should be noted that one of the IETF RATS may be used to perform the mutual attestation based on hardware components of the computing device 108 and the second device.

In some examples, the handshake may be performed between the data-sharing manager 250 of the computing device 108 and the second device before the first device initiates accessing the second device. In some examples, the handshake may be performed between the data- sharing manager 250 of the computing device 108 and the second device afterthe first device is successfully authenticated and authorized to access the second device. The data-sharing manager 250 further receives a first request from the second device via the established secure channel between the computing device and the second device. The first request is for the private data. In some examples, the first request may indicate at least one of: a device for which the private data is requested (for example herein, first device), an amount of private data, and a type of private data.

Upon receiving the first request for the private data, the data-sharing manager 250 determines whether the second device is equipped with the session ID of the first device. When it has been determined that the second device is equipped with the session ID of the first device, the data-sharing manager 250 transmits the requested private data to the second device via the established secure channel between the computing device 108 and the second device.

For transmitting the private data to the second device, the data-sharing manager 250 may identify the at least one task of the first device (user of the first device) to be performed on the second device. The at least one task referred herein may be performed using applications being executed on the second device such as, but are not limited to, a camera, a microphone, a speaker, a display application, a streaming application, a navigation application, a gaming application, and so on.

The data-sharing manager 250 may determine whetherthe requested private data is relevant for performing the identified at least one task on the second device. Consider an example scenario, wherein private data requested by the second device may include application settings and application data and a task of the first device may be performed on the second device using a gaming application. In such a scenario, the data-sharing manager 250 determines if the requested application settings and application data are related to the gaming application and are required for executing the gaming application on the second device. If the requested application settings and application data are related to the gaming application and are required for executing the gaming application on the second device, the data-sharing manager 250 may determine that the requested private data is relevant for performing the at least one task of the first device on the second device. If the requested application settings and application data are not related to the gaming application and/or are not required for executing the gaming application on the second device, the data-sharing manager 250 may determine that the requested private data is not relevant for performing the at least one task of the first device on the second device.

When it has been determined that the requested private data is relevant for performing the at least one task of the first device on the second device, the data-sharing manager 250 may verify whether the second device is an authenticated and authorized device to receive the requested private data. In some examples, an OpenlD connect and Oauth2.0 may be used to authenticate and authorize the second device. Upon verifying that the second device is the authenticated and authorized device, the data-sharing manager 250 may transmit the requested private data to the second device.

For transmitting the requested private data to the second device, the data-sharing manager 250 may identify the first device for which the private data is requested from the second device. The data-sharing manager 250 may fetch the requested private data associated with the identified first device from the database 260 or the data source 270a dedicated for the identified first device. The data-sharing manager 250 may further transmit the requested private data to the second device.

In some example, the data source 270a comprises an offered service that may be present in at least one software-as-a-service, or in a computer -as-a-service and/or in a storage-as-a- service.

In some examples, the data-sharing manager 250 may provide all the requested private data to the second device at a time. In some examples, the data-sharing manager 250 may provide part of the private data at a time while the at least one task is performed on the second device. In some examples, the data-sharing manager 250 may divide the requested private data into a plurality of data chunks based on the at least one task to be performed on the second device. The data-sharing manager 250 may transmit the plurality of data chunks to the second device sequentially, while the at least one task is performed on the second device. Thus, the data transmission may be performed in a secure manner as well as efficiency of the data transmission may be improved when the data size is large.

When it has been determined that second device is no longer equipped with the session ID of the first device or when the requested private data is not relevant for the at least one task or when the second device is not the authenticated and/or authorized device, the data-sharing manager 250 obviates transmission of the private data to the second device.

In some examples, the data-sharing manager 250 may be further adapted to receive, from the second device, at least one of: newly created or modified private data on the second device while the at least one task of the first device is performed on the second device. In some examples, said data may include preferences altered by the user on the second device, updated usage statistics of certain components in the second device, etc. Said data may be received via the secure channel established between the second device and the computing device 108.

In some examples, the data-sharing manager 250 may be further adapted to perform one or more data handling actions, when the first device or the second device is performing any unauthorized action.

For performing the one or more data handling actions, the data-sharing manager 250 may monitor information flow of data related to the first device while the at least one task of the first device is performed on the second device. In some examples, the second device requests determining what data and which task the second device is performed while requesting said data. In some examples, the information related to the first device may identify at least one of: an amount of private data accessed from the second device and requests for performing one or more (additional) tasks on the second device. Similarly, the data-sharing manager 250 may monitor via a log and analyse instance, information related to the second device while the at least one task of the first device is performed on the second device. In some examples, the information related to the second device may identify at least one of: an amount of private data and a type of private data requested or used by the second device and a frequency associated with generation of requests from the second device forthe private data.

The data-sharing manager 250 may evaluate the monitored information related to the first device and the second device to determine whether the first device or the second device is performing any unauthorized action. In some examples, the unauthorized action performed by the first device and the second device may comprise, but are not limited to the at least one task that is unauthorized to be performed on the second device, requesting for the private data that is not relevant for the at least one task of the first device, and so on. When it has been determined that the first device or the second device is performing any unauthorized action, the data-sharing manager 250 may perform the one or more data handling actions to prevent the first device or the second device performing any unauthorized action. Examples of the data handling actions may include, but are not limited to, terminating transmission of the private data to at least one of the first device or the second device, transmitting an indication to the second device to terminate the at least one task being performed on the second device, transmitting an indication to the second device or the first device to disconnect a session established between the second device and the first device.

In some examples, the data-sharing manager 250 may be further adapted to request the second device to remove the transmitted private data, upon expiration of the session ID of the first device equipped by the second device. The data-sharing manager 250 may receive, from the first device and/or the second device, a second request indicating an expiry of the session ID of the first device equipped by the second device. Expiry of the session ID may indicate a termination of a communication session between the first device and the second device. Upon receiving the second request, the data-sharing manager 250 may request the second device to remove the transmitted private data.

The data-sharing manager 250 may be further adapted to receive a termination message from the second device. The termination message may indicate that the second device has removed the transmitted private data and indicate to terminate a communication session between the second device and the computing device 108. Said message may further be signed by a cryptographic key embedded in a trusted part of the second device to raise the trustworthiness of the data having been removed from the second device.

Fig. 3 is a signaling diagram illustrating example signaling for handling private data in a secure environment (now shown in Fig.). As depicted in Fig. 3, there exists a computing device 108 arranged to execute in the secure environment. The computing device 108 is in communication with a plurality of second devices. A second device 104 among the plurality of second devices is accessed by a first device 102 for at least one time instance/temporarily/occasionally. In some examples, as depicted in Fig. 3, the first device 102 may directly communicate with both the computing device 108 and the second device

104. In some examples, the computing device 108 may be managed by a same service provider, who is providing a lending application for the first device 102 to access the second device 104. In some examples, the computing device 108 may be managed by a different service provider. In such a scenario, the computing device 108 may be connected to a computing device/service domain of the service provider providing the lending application for the first device 102.

As depicted in Fig. 3, at step 301, a mutual attestation is performed between the second device 104 and the computing device 108. The mutual attestation may enable the second device 104 to register with the computing device 108 (i.e., to identify themselves to the computing device 108). The mutual attestation may include performing a handshake between the computing device 108 and the second device 104. In some examples, the mutual attestation may include hardware attestation as well as software attestation.

Upon successful mutual attestation, a secure channel is established between the computing device 108 and the second device 104. In some examples, the computing device 108 may establish secure channels (i.e., setup connections) with several similar second devices. The secure channel between the computing device 108 and the second device 104 may be terminated at a Trusted Execution Environment, TEE, within the second device 104, which may be remotely attested by the computing device 108.

Optionally, upon the successful mutual attestation between the computing device 108 and the second device 104, the computing device 108 may activate a log and analyse instance for the second device 104, which tracks requests raised by the second device 104 against data belonging to the first device.

In an example, in step 301a, each of the first device 102 and the second device 104 authenticated through the computing device on at least one of a token, the session ID or the authenticated session.

It should be understood that if the computing device 108 is managed by the same service provider providing the lending application for the first device 102 to access the second device 104, then the mutual attestation between the computing device 108 and the second device 104 may be performed at 301 (i.e., prior to establishing a session between the first device 102 and the second device 104). If the computing device 108 is managing by the different service provider and/or if the computing device 108 is a user selected computing device, then the computing device 108 may later connect to the computing device/service domain of the service provider when the first device 102 wants to access the second device 104. Thus, the mutual attestation between the computing device 108 and the second device 104 may be performed after/during step 304 (i.e., after establishing the session between the first device 102 and the second device 104).

At step 302, the first device 102 and the computing device 108 mutually identifies themselves by performing a mutual attestation between the first device 102 and the computing device 108. Upon successful mutual attestation between the first device 102 and the computing device 108, a secure channel is established between the first device 102 and the computing device 108.

The mutual attestation performed between the first device 102/second device 104 and the computing device 108 is described in detail in conjunction with Fig. 5.

The computing device 108 may perform an authentication process to authenticate the first device 102 before establishing the secure channel. After the successful authentication, the attestation of first device 102 is performed through the computing device 108.

Optionally, once the secure channel is established between the first device 102 and the computing device 108, at step 303a, the first device 102 transmits profile data to the computing device 108 via the secure channel after the authentication and attestation. Examples of the profile data of the first device may include, but are not limited to, configurations and application data of the first device, physical traits, and personal preferences of the user associated with the first device, expected usage patterns of the first device by the respective user, historical usage patterns of the second devices by the user through the first device (for example, the tasks performed on the second devices), or the like.

. Upon successfully authenticating the first device 102, at step 303b, the computing device 108 transmits a session identifier, ID, to the first device 102. The session ID may act as a temporary ID for the first device 102. The session ID may be used in a form of a key, a token, or the like. In an example, the authentication and authorization may happen before attestation in one scenario or after the attestation in another scenario before the transmission of the private data.

Upon receiving the session ID from the computing device 108, the first device 102 initiates accessing of the second device 104. The first device 102 may initiate accessing of the second device 104 by picking an instance of the second device 104. For example, the first device 102 may scan a QR code printed on the second device 104 to initiate accessing of the second device 104. After initiating accessing of the second device 104, at step 303c, the first device 102 transmits the session ID to the second device 104.

After receiving the session ID from the first device 102, at step 304, the second device 104 initiates an authentication and authorization procedure (possibly with an external authorization server and involving the computing device 108) to determine whether the first device 102 is an authenticated and authorized device to access the second device 104. In some examples, the authentication and authorization procedure may utilize privacy preserving procedures that is the authentication and authorization procedure may utilize the temporary/session ID assigned for the first device 102 (at step 304). Alternatively, the authentication and authorization procedure may utilize the session ID received by the computing device 108 from the first device 102 in advance during the authentication of the first device 102. Thus, the computing device 108 may act as a proxy, which does not use a real identifier of the first device 102 or does not reveal the real identifier of the first device 102 or the user of the first device to the second device 104, when the first device 102 is in communication with the second device 104. The authentication and authorization procedure is described in detail in conjunction with Fig. 5.

When it has been determined that the first device 102 is the authenticated and authorized device to access the second device 104, at step 305a, the second device 104 transmits a first request to the computing device 108 via the secure channel established between the second device 108 and the computing device 108. The first request is for private data and is adapted for performing one or more tasks on behalf of the first device 102 on the second device 104. In some examples, the private data may comprise at least a part of the profile data of the first device 102 (for example, preferences/user settings associated with the user of the first device 102). In some examples, the private data may comprise at least the part of the profile data of the first device 102 and a profile data of an owner/entity associated with the second device 104. At step 305b, the computing device 108 provides the requested private data to the second device 104 via the established secure channel, when the requested private data is relevant to the tasks performed on behalf of the first device 102 and/or the second device is the authenticated and authorized device to access the private data.

Further, during an operation of the second device 104 (i.e., while performing the tasks on behalf of the first device 102 on the second device 104), at step 306a, the second device 104 may request the computing device 108 for additional private data for the first device 102 via the secure channel. At step 306b, the computing device 108 provides the requested additional private data to the second device 104 via the established secure channel, when the requested additional private data is relevant to the tasks performed on behalf of the first device 102 and the second device is the authenticated and authorized device to access the additional private data.

Further, during the operation of the second device 104 (i.e., while performing the tasks on behalf of the first device 102 on the second device 104), at step 307, the second device 104 transmits newly created or modified private data to the computing device 108. It should be noted that steps 306a and 307 may be performed in arbitrary order and each of these steps may also be repeated arbitrary number of times during accessing of the second device 104 by the first device 102.

When the first device 102 terminates accessing of the second device 104, at step 308a, the second device 104 transmits a second request/shutdown request to the computing device 108. Optionally, at step 308b, the first device 102 may also/instead transmit the shutdown request to the computing device 108. The second/shutdown request may indicate an expiry of the session ID of the first device 102 equipped by the second device 104 (i.e., indicating termination of the communication session between the first device 102 and the second device 104).

Upon receiving the shutdown request, at step 308c, the computing device 108 requests the second device 104 to remove the private data provided for the one or more tasks performed on behalf of the first device 102. Upon removing the private data, at step 308d, the second device 104 transmits a termination message (also be referred to as trustworthy termination message, TEE termination message, or the like) to the computing device 108. The termination message may confirm that measures have been taken to remove/erase the private data on the second device 104 and to terminate the communication session between the first device 102 and the second device 104. Said message may further be signed by a cryptographic key embedded in a trusted part of the second device to raise the trustworthiness of the data having been removed from the second device. Optionally, the computing device 108 may also transmit a termination message to the first device 102 indicating that the session ID has been revoked, the private has been removed on the second device 104, and the communication session has been terminated between the first device 102 and the second device 104.

Thus, whenever accessing/usage of the second device 104 is terminated, the private data may be erased from a volatile or non-volatile memory, cache, register or the like of the second device 104 and the session ID assigned for the first device 102 may be revoked by the computing device 108. Thus, the private/profile data of the user/first device may be secured.

Consider an example scenario, wherein the computing device 108 is in communication with a pool of second devices/lending devices 104. For instance, the pool may comprise vehicles, Extended Reality, XR, headsets, devices, or the like. The vehicles may be owned by a car rental service. The XR headsets may be owned by a museum or other establishment offering interactive virtual experience. The devices may be owned by a company offering device-as-a service. All these second devices may be connected to the computing device 108. When a new second device is added to the pool, an on-boarding process including the mutual attestation between the new second device and the computing device 108 may be performed (as described at step 301).

At a later point in time, a user of the first device 102 decides to access the second device 104 in the pool. For accessing the second device 104, the first device 102 may download a lending application provided by the service provider to access the second device 104. During installation and initiation of the lending application, a mutual attestation may be performed between the first device and the computing device 108 (as described at step 302). At a last step of initialization of the lending application or at any time, the first device 102 may upload the profile data (for example: user settings) to the computing device 108 via the secure channel established between the first device 102 and the computing device 108 based on the mutual attestation. The first device 102 identifies an instance of the second device 104 and initiates a pairing procedure to connect to the second device 104. In some examples, the first device 102 may use a code or a passphrase or biometrics to connect to the second device 104. In some examples, the first device 102 may connect to the second device 104 using the lending application. In some examples, the first device 102 may use a short-range communication interface like Bluetooth to connect to the second device 104, which may provide a means of establishing proof of presence/locality. The first device 102 may use the short-range communication interface to connect with the second device 104, when both the first device 102 and the second device 104 are in a certain proximity to each other. Once the first device 102 is connected to the second device 104, the second device 104 in conjunction with the computing device 108 may perform the authentication and authorization procedure (as described at step 304) using the application (possibly credentials) to authenticate and authorize the first device 102/user of the first device 102. If the authentication and authorization is successful, the computing device 108 checks whether the first device 102 or the user of the first device 102 is allowed to access the second device 104 temporarily/occasionally. If the first device 102 is allowed to access the second device 104 temporarily, the second device 104 may be equipped with the session ID (token ortemporary ID) of the first device 102 to enable fetching relevant private data for the tasks performed on behalf of the first device 102.

During accessing of the second device 104 by the first device 102, the second device 104 may continuously request the computing device 108 for the private data comprising at least a part of the profile data of the first device 102 (for example, application settings and personal data) via the secure channel (as described at steps 305a and 306a). Similarly, during accessing of the second device 104 by the first device 102, the second device 104 may continuously upload newly created or modified private data from its TEE to the computing device 108.

When the first device 102 terminates accessing the second device 104 (i.e., when the user of the first device 102 returns the second device 104), the first device 102 may terminate execution of the lending application. The lending application may transmit the shutdown request to the computing device 108 for shutdown and disconnection. In response to reception of the shutdown request, the computing device 108 requests the second device 104 to wipe/erase/remove all the private data related to the session ID of the first device 102 from its TEE. The second device 104 may confirm the computing device 108 about the removal of the private data. Thereafter, the computing device 108 revokes the session ID provided to the first device 102.

Fig. 4 is a signaling diagram illustrating example signaling for handling private data in a secure environment. As depicted in Fig. 4, there exists a computing device 108 in the secure environment. The computing device 108 is in communication with a plurality of second devices. A second device 104 among the plurality of second devices is accessed by a first device 102 for at least one time instance/temporarily/occasionally.

In some examples, as depicted in Fig. 4, the first device 102 may be a constrained device having limited communication and processing capabilities, so that the first device 102 may communicate with the computing device 108 through the second device 104. In such a scenario, the first device 102 may comprise a user tag and the second device may comprise an Input/Output device, IOD. For instance, the first device 102 and the second device 104 may comprise a payment card and a card reader, respectively.

In some examples, the computing device 108 may be in communication with multiple data sources (as described in Fig. 2B) in which the multiple data sources are dedicated for storing information/profile data related to the multiple first devices. In such a scenario, the computing device 108 may act as an IOD handler, IODH. The IODH may request information/profile data related to the first device 102 from a data source dedicated for the first device 102. In some examples, the computing device 108 may comprise a database to store information/profile data related to multiple first devices. In such a scenario, the computing device 108 may act as a dedicated data source for the first device 102 and the IODH may be used to add the second device 104 to first device's session.

As depicted in Fig. 4, at step 401, a mutual attestation is performed between the second device 104 and the computing device 108 to establish a secure channel between the second device 104 and the computing device 108. The mutual attestation may enable the second device 104 to register with the computing device 108 (i.e., to identify themselves to the computing device 108). The mutual attestation includes performing a handshake between the computing device 108 and the second device 104. In some examples, the mutual attestation may include hardware attestation as well as software attestation. Optionally, upon successful attestation between the computing device 108 and the second device 104, the computing device 108 may activate a log and analyse instance for the second device 104, which tracks requests raised by the second device 104 against the first device.

In some embodiments of this scenario, the second device is an IOD providing device capabilities such as: screen, microphone, speaker, camera etc. to a session controlled by the userowningthe first device. The second device belongto a IOD domain, i.e., a pool of devices, and is controlled by an IOD Handler (IODH). The session for the user is hosted in a cloud service or the like, here referred to as dedicated data source.

It should be understood that if the computing device 108 is the dedicated data source for the first device 102, the mutual attestation between the second device 104 and the computing device 108 may be performed in conjunction with steps 402 (collectively referred to steps 402a and 402b) and 404, or any time before steps 402 or 404 (collectively referred to steps 404a-404d).

At step 402a, the first device 102 initiates a communication session with the second device 104 that the first device 102 wants to access for at least one time instance. In some examples, initiating the communication session with the second device 104 may include the first device 102 authenticating itself to its dedicated data source 270a via an IOD, for example, the second device 104, and an IOD domain to which the second device 104 belongs. Thereby, the first device 102 may be authenticated to the IOD domain, so that the IOD domain may create the communication session between the second device 104 and the first device 102. Further, authentication may also lead to security parameters such as: shared secret, session ID that can be used for creating a secure connection between the second device 104 and data source, and/or between the computing device 108 (if part of IOD domain) and data source. As well as the first device 102 may be authenticated to the dedicated data source 270a, so that the computing device 108 may identify the first device 102 and determine that the first device 102 wants to use services in the IOD domain (i.e., to access the second device). As a result, the IOD domain may also learn the dedicated data source 270a of the first device 102, so that the IOD domain may contact such dedicated data source 270a via the computing device 108. In some examples, initiating the communication session with the second device 104 may include performing an authorization process, which may be used to determine under which circumstances or scenarios the first device 102 is allowed to access the second device 102. Further, accounting and billing procedures may also be performed when the first device 102 initiates the communication session with the second device 104.

Upon the successful authentication and authorization procedure, at step 402b, the first device 102 may be assigned with the session ID via the second device 104.

At step 403, the first device 102 transmits the profile data to the computing device 108/dedicated data source 270a through the second device 104. The computing device 108 may store the profile data of the first device 102 in the database 260. Transmission of the profile data may be performed any time before, after, and during the communication session initiated between the first device 102 and the second device 104.

At step 404a, the second device 104 requests the computing device 108 for private data. The private data may be adapted for performing the one or more tasks on behalf of the first device 102 on the second device 104. In some examples, the private data may comprise at least a part of the profile data of the second device 104. In some examples, the private data may comprise at least the part of the profile data of the second device 104 and profile data of the owner/entity associated with the second device 104.

In some examples, if the computing device 108 is the IODH, the second device 104 may request the private data (i.e., the profile data of the first device 102) based on the session ID of the first device 102. In such a scenario, at steps 404b, 404c, and 404d, the computing device 108 may access the profile data of the first device 102 from the data source 270a dedicated for the first device 102 and transmits the accessed profile data to the second device 104. In some examples, the connection between the second device 104 and the lODH/computing device 108 may be secured based on the IODH of the second device 104. In some examples, the connection between the second device 104 and the lODH/computing device 108 may be secured based on credentials derived from the authentication of the first device 102 to its dedicated data source via the computing device 108 in a similar way as the IOD may obtain credentials for connecting to the dedicated data source of the first device 102 via the computing device 108.

In some examples, if the computing device 108 is the dedicated data source for the first device 102 (i.e., the computing device 108 maintaining the single database 260 for the multiple first devices), the IODH used by the computing device 108 may identify the computing device 108 from the authentication of the first device 102. Further, the IODH may obtain credentials for the second device 104 and provide the credential of the second device 104 to the second device 104. The second device 104 may use the credentials to set up the secure channel with the computing device 108 and then request the computing device 108 to share the private directly over the secure channel. In such a scenario, at steps 404b, 404c, and 404d, the computing device 108 may access the profile data of the first device 102 from the database 260 and transmits the accessed profile data to the second device 104.

Further, during an operation of the second device 104 (i.e., while performing the tasks on behalf of the first device 102 on the second device 104), at step 405a, the second device 104 may request the computing device 108 for additional private data for the first device 102 via the secure channel. At steps 405b, 405c and 405d, the computing device 108 accesses the additional private data from the database 260 orthe dedicated data source 270a and provides the requested additional private data to the second device 104. The additional private data may be provided to the second device 104, when the requested additional private data is relevant to the tasks performed on behalf of the first device 102 and/or the second device is the authenticated and authorized device to access the additional private data.

Further, during the operation of the] second device 104 (i.e., while performing the tasks on behalf of the first device 102 on the second device 104), at step 406, the second device 104 transmits newly created or modified private data to the computing device 108. It should be noted that steps 405a and 406 may be performed in arbitrary order and each of these steps may also be repeated arbitrary number of times during accessing of the second device 104 by the first device 102.

When the first device 102 terminates accessing of the second device 104, at step 407a, the second device 104 transmits a second request/shutdown request to the computing device 108. The second/shutdown request may indicate an expiry of the session ID of the first device 102 equipped by the second device 104 (i.e., indicating termination of the communication session between the first device 102 and the second device 104).

Upon receiving the shutdown request, at step 407b, the computing device 108 requests the second device 104 to remove the private data provided for the one or more tasks performed on behalf of the first device 102. Upon removing the private data, at step 407c, the second device 104 transmits a termination message (also be referred to as trustworthy termination message, TEE termination message, or the like) to the computing device 108. The termination message may confirm that measures have been taken to remove/erase the private data on the second device 104 and to terminate the communication session between the first device 102 and the second device 104. Said message may further be signed by a cryptographic key embedded in a trusted part of the second device to raise the trustworthiness of the data having been removed from the second device.

Consider an example scenario, wherein there exists a pool of second devices, for example, vehicles, machines/robots, smart phones, or the like. The devices in the pool of second devices are in communication with the computing device 108. For instance, the computing device 108 may be an IODH. That is the computing device/IODH 108 may be in communication with one or more data sources dedicated for one or more first devices. When a new second device is added to the pool, an on-boarding process including the mutual attestation between the TEE of the new second device and the IODH may be performed (as described at step 401).

Further, a user wants to use the second device 104 from the pool. The user presents the session ID (temporary ID) to a particular instance of the second device 104 for instance using the first device 102. Herein the first device 102 may be a user tag. This may trigger the user tag to be authenticated to the dedicated data source of the user tag through the IODH or the IOD domain of the second device (as descried at step 402). Optionally, upon successful authentication of the user tag, the user tag uploads the profile data (for example, user settings) to the dedicated data source via the second device 104. The user tag may upload the profile data to the dedicated data source at any time or whenever the user tag has any new data available.

Further upon successful authentication of the user tag, the second device 104 requests the private data from the computing device/IODH 108 via the secure channel established between the second device 104 and the computing device 108. The secure channel referred herein may be a pre-existing channel established between the second device 104 and the computing device 108. The secure channel may be established as a result of authentication described at step 402. In some examples, the requested private data may be for the information/profile data of the user tag that has already existed in the dedicated data source of the user tag. In some examples, the requested private data may be for the profile data created by the computing device 108 based on the profile data of the user tag at step 403.

During an operation of the second device 104, the second device 104 may further request the computing device 108 for additional private data relevant to the user tag (as described at steps 405a and 405b). In addition, the second device 104 may also upload newly created or modified private data to the computing device 108 while performing one or more tasks related to the user tag (as described at step 406). When the user returns the second device 104, the private data stored on the second device 104 as well as the session ID associated with the user tag may be removed/erased.

Fig. 5 is a signaling diagram illustrating example step by step flow for handling private data in a secure environment. The secure environment comprises a computing device 108, which is adapted to handle data sharing in the secure environment. The computing device 108 is further adapted to be in communication with pool of second devices. Any of the second devices, for example, a second device 104 is accessed by a first device 102 for temporarily/occasionally/at least one time instance. In the example described in Fig. 5, it should be considered that the first device 102 may interface with both the second device 104 and the computing device 108. The computing device 108 may comprise a database 260 and execute application instances such as an authentication service instance 502, an authorization service instance 504, and attestation service instance 506 on a kernel (as described above in Figs. 2A and 2B). The computing device 108 may provide a lending application, which may be used by the first device 102 to access the second device 104 and to interact with the computing device 108.

A user may request the first device 102 to access the second device 104. Optionally, upon receiving the request from the user, the first device 102 and the computing device 108 may perform a mutual attestation to establish a secure channel between the first device 102 and the computing device 108. The mutual attestation may involve a handshake between the first device 102 and the computing device 108. For example, as depicted in Fig. 5, the first device 102 may request an attestation quote from the computing device 108. The computing device 108 may provide the requested attestation quote to the first device 102 by executing the attestation service instance 506. Similarly, the computing device 108 may request the first device 102 for the attestation quote. The first device 102 may provide the attestation quote to the computing device 108. Upon the successful mutual attestation between the first device 102 and the computing device 108 based on the attestation quote, the secure channel may be established between the first device 102 and the computing device 108.

The first device 102 may invoke an authentication procedure with the computing device 108 to establish the secure channel with the computing device 108. The first device 102 may invoke the authentication procedure by sending a request to the authentication service instance 502 of the computing device 108. The authentication service instance 502 may instruct the first device 102 to redirect to a login page of the lending application provided by the computing device 108. By redirecting to the login page, the first device 102 may provide credentials such as username and password to the authentication service instance 502. The authentication service instance 502 may check whether the received credentials match with credentials for the user of the first device 102. If the received credentials match with the stored credentials of the user, the authentication service instance 502 may identify successful authentication of the first device 102/user of the first device 102 and provide a session identifier, ID (ID token) to the first device 102.

Upon receiving the session ID from the authentication service instance 502, the authentication service instance 502 may share the session ID with the second device 104 that the user of the first device 102 wants to access. Alternatively, the first device 102 may also share the session ID with the second device 104. The second device 104 may initiate an authentication and authorization procedure to authenticate the first device 102. In some examples, the authentication and authorization procedure may include sending by the second device 104 the session ID of the first device 102 to an authorization service instance 510 executed on an external computing device. The external computing device herein may be a resource server. In some examples, the external computing device and the computing device may act as two different entities, but still under a control of a same service provider. The authorization service instance 510 may send the session ID of the first device 102 to the authentication service instance 502 of the computing device 108 and receive user attributes related to the first device 102 from the authentication service instance 502. The authorization service instance 510 may determine whether the first device 102 is authenticated and authorized device to access the second device 104 based on the user attributes from the authentication service instance 502. The authorization service instance 510 may further provide results of the determination to the second device 104.

When it has been determined that the first device 102 is authenticated and authorized device to access the second device 104, the second device 104 may initiate a mutual attestation with the attestation service instance 506 of the computing device 108. The mutual attestation may involve a handshake between the second device 104 and the computing device 108. For example, as depicted in Fig. 5, the second device 104 may request attestation quote from the attestation service instance 506. The attestation service instance 506 may provide the requested attestation quote to the first device 102. Similarly, the attestation service instance 506 may request the second device 104 for the attestation quote. The second device 104 may provide the attestation quote to the attestation service instance 506. Upon the successful mutual attestation between the second device 104 and the computing device 108 based on the shared attestation quotes, the secure channel may be established between the second device 104 and the computing device 108.

Upon the successful mutual attestation, the second device 104 may invoke an authentication with the authentication service instance 502 of the computing device 108 and may receive a device token (related to the second device 104) from the authentication service instance 502. The second device 104 may send the device token and the session ID of the first device 102 to the authorization service instance 504 of the computing device 108. Upon receiving the device token and the session ID from the second device 104, the authorization service instance 504 may receive the user attributes related to the received session ID from the authentication service instance 502. Based on the user attributes, the authorization service instance 504 may determine whether the second device 104 is authenticated and authorized device to access private data for one or more tasks performed on behalf of the first device 102 to be performed on the second device 104. When it has been determined that the second device 104 is the authenticated and authorized device to access the private data, the authorization service instance 504 may grant an authorization token to the second device 104 for accessing the private data.

During an operation of the second device 104/accessing of the second device 104 by the first device 102, the second device 104 may send multiple requests to the computing device 108 for the private data. The request may include the session ID, and the authorization token. The computing device 108 may verify the session ID and the authorization token received from the second device 104. Upon successful verification, the computing device 108 may fetch the requested private data from the database 260 and provide the requested private data to the second device 108. In some examples, the private data may comprise at least a part of profile data of the first device 102 and/or profile data of the owner associated with the second device 104.

Further, during the operation of the second device 104, the second device 104 may further update the computing device 108 about the modified or newly created private data by sending the session ID, the authorization session, and the modified or newly created private data to the computing device 108. Upon successful verification of the session ID, the authorization session, and the modified or newly created private data, the computing device 108 may decide to accept or reject reception of the modified or newly created private data from the first device 102.

Fig. 6 is a flowchart depicting example method steps of a method 600 for data sharing in a secure environment. The method 600 is performed by a computing device deployed in the secure environment. The computing device is in communication with a second device. The second device is configured to be accessed by a first device for at least one time instance (i.e. for temporarily/instantly).

At step 602, the method 600 comprises performing a handshake with the second device to establish a secure channel between the second device and the computing device. In some examples, the attestation may be performed using any of the suitable IETF RATS protocols.

At step 604, the method 600 comprises receiving from the second device via the established secure channel, a first request for private data. In some examples, the first request received from the second device may indicate at least one of: a device for which the private data is requested, an amount of private data, and a type of private data. In some embodiments, the private data comprises a profile data of at least entity operating the second device along with at least the part of the profile data of the first device. Examples of the profile data of the first device may include, but are not limited to, configurations and application data of the first device, physical traits, and personal preferences of the user associated with the first device, expected usage patterns of the first device by the respective user, historical usage patterns of the second devices by the user through the first device (for example, the tasks performed on the second devices), or the like. Examples of the profile data of the owner associated with the second device may include, but are not limited to, application settings for applications being executed on the second device(s), credentials to be used for executing the applications on the second device, and so on.

Upon receiving the first request, at step 606, the method 600 comprises determining whether the second device is equipped with a session identifier, ID, of the first device. In some examples, the session ID may comprise at least one of: a permanent identifier, a temporary identifier, a token, and a key assigned by the computing device for the first device to establish a communication session with the second device. The computing device may assign the session ID to the first device upon receiving profile data from the first device.

In an example, the session ID is an anonymous and temporary ID of the first device 102 (keeping the first device 102 anonymous) allocated for each session between the computing device 108 and the second device 104. In another example, the session ID may also comprise an ID of the second device 104 shared with the first device 102 and may comprise a scan QR code on the second device 104 which is shared with the computing device 108, either as part of authentication to get token, or as a trigger for the computing device 108 to provide the private data to the second device 104.

In some examples, the computing device may perform a handshake (for example according to IETF RATS protocols) with the first device to establish a secure channel between the first device and the computing device. The computing device may receive the profile data of the first device via the secure channel established between the first device and the computing device. In some examples, the computing device may receive the profile data of the first device via the second device. Upon receiving the profile data, the computing device may store the profile data in the database or in a data source dedicated for the first device and assign the session ID for the first device. The session ID may be used to determine whether the first device is an authenticated and authorized device to access the second device. Thus, the first device may be authenticated and authorized without revealing a real identity of the first device to the second device. When it has been determined that the second device is equipped with the session ID of the first device, at step 608, the method 600 comprises transmitting the requested private data to the second device via the established secure channel. The private data comprises at least a part of profile data of the first device and is adapted for performing at least one task associated with the first device on the second device.

In some examples, the step 608 of transmitting the requested private data to the second device may comprise identifying the at least one task to be performed on the second device, wherein the at least one task is associated with the first device. The at least one task may be performed using applications being executed on the second device such as, but are not limited to, a camera, a microphone, a speaker, a display application, a streaming application, a navigation application, a gaming application, and so on. The method may comprise determining whether the requested private data is relevant for performing the identified at least one task on the second device. When it has been determined that the requested private data is relevant for performing the at least one task, the method may comprise verifying whether the second device is an authenticated and authorized device to receive the requested private data. Upon verifying that the second device is the authenticated and authorized device, the method may comprise transmitting the requested private data to the second device. Verification of the second device is described detail in conjunction with Fig. 5, thus repeated description is omitted herein.

In some examples, the step 608 of transmitting the requested private data to the second device may further comprise identifying the first device for which the private data is requested from the second device. The method may comprise fetching the requested private data associated with the identified first device from the database or the data source dedicated for the identified first device. The method may further comprise transmitting the requested private data to the second device via the established secure channel.

In some examples, the step 608 of transmitting the requested private data to the second device may further comprise dividing the requested private data into a plurality of data chunks based on the at least one task to be performed on the second device. The method may further comprise transmitting the plurality of data chunks to the second device sequentially, while the at least one task being performed on the second device. Said data chunks may be sent after determining the second device having a need to receive the data to perform a task. Thus, privacy and data transmission may be improved, when the private data is large in size. In addition, especially for the private data comprising application data, the computing device may analyse whether the first request from the second device is warranted or considered too broad and accordingly proceed to transmit the private data in the suitable chunks instead of all at once.

Optionally, at step 610, the method 600 may comprise receiving, from the second device via the secure channel established between the second device and the computing device, at least one of: newly created or modified private data on the second device while the at least one task associated with the first device is performed on the second device.

Optionally, at step 612, the method 600 may further comprise performing one or more data handling actions when the first device or the second device is performing any unauthorized action. The step 612 may comprise monitoring information related to the first device while the at least one task associated with the first device is performed on the second device. In some embodiments, the information related to the first device identifies at least one of: an amount of private data accessed from the second device and requests for performing one or more tasks on the second device. Similarly, the method may comprise monitoring, via a log and analyse instance, information related to the second device while the at least one task associated with the first device is performed on the second device. In some embodiments, the information related to the second device identifies at least one of: an amount of private data and a type of data requested or used by the second device and a frequency associated with generation of requests from the second device for the private data.

Based on evaluation of the monitored information related to the first device and the second device, the method may comprise determining whether the first device or the second device is performing any unauthorized action. In some embodiments, the unauthorized action comprises at least one of: requesting for the private data that is not relevant for the at least one task of the first device, requesting data for performing the at least one task that is unauthorized to perform on the second device, requesting for performing the at least one task manipulating data that is unauthorized to perform on the second device. The at least one task is performed on the second device. When it has been determined that the first device or the second device is performing any unauthorized action, the method may comprise performing one or more data handling actions to prevent the first device or the second device from performing any unauthorized action. In some embodiments, the step of performing the one or more data handling actions comprises one or more of: terminating transmission of the private data to the second device, transmitting an indication to the second device to terminate the at least one task being performed on the second device, and transmitting an indication to the second device or the first device to disconnect a session established between the second device and the first device. Thus, the first and second devices may be monitored and evaluated to determine a type of the private data used and when the private data is used.

Optionally, at step 614, the method 600 may further comprise requesting the second device to remove the private data, upon expiration of the session ID of the first device equipped by the second device. The step 614 may comprise receiving, from at least one of: the second device and the first device, a second request indicating an expiry of the session ID of the first device equipped by the second device. Upon receiving the second request, the method 600 may comprise requesting the second device to remove the transmitted private data.

In some examples, the method 600 may further comprise receiving a termination message from the second device. The termination message indicating that the second device has removed the transmitted private data and indicating to terminate a communication session between the second device and the computing device. Thus, the computing device may obtain a proof that the private data has been removed. In some examples, the termination message may further be signed by a cryptographic key embedded in a trusted part of the second device 104 to raise the trustworthiness of the data having been removed from the second device 104.

Fig. 7 is a flowchart illustrating method steps of a method 700 performed for data access in a secure environment is provided. The second device is in communication with a computing device in the secure environment and accessed by a first device for at least one time instance.

At step 702, the method 700 comprises performing a handshake with the computing device to establish a secure channel between the second device and the computing device. In some examples, the handshake may performed using any of the suitable IETF RATS protocols. At step 704, the method 700 comprises transmitting, to the computing device via the established secure channel, a first request for private data. The private data comprising at least a part of profile data of the first device and/or at least a part of profile data of an entity operating the second device. Examples of the profile data of the first device may include, but are not limited to, configurations and application data of the first device, physical traits, and personal preferences of the user associated with the first device, expected usage patterns of the first device by the respective user, historical usage patterns of the second devices by the userthrough the first device (for example, the tasks performed on the second devices), or the like. Examples of the profile data of the entity associated with the second device may include, but are not limited to, application settings for applications being executed on the second device(s), credentials to be used for executing the applications on the second device, and so on.

In some examples, prior to the step 704, the method 700 may comprise receiving the session ID from the first device, upon connecting with the first device. In some examples, a communication session may be established between the first device and the second device using a long-range communication (for example, cellular communication). In some examples, the communication session may be established between the first device and the second device using a short-range communication (for example, Bluetooth).

Upon receiving the session ID, the method 700 may comprise verifying, in conjunction with the computing device, whether the first device is an authenticated and authorized device to access the second device based on the received session ID. Verification of the first device is described in detail in conjunction with Fig. 5, thus repeated description is omitted herein. Upon verifying that the first device is the authenticated and authorized device to access the second device, the method 700 may comprise deciding to transmit the first request for the private data.

In response to transmitting the first request, at step 706, the method 700 comprises receiving, from the computing device via the established secure channel, the requested private data, when the second device is equipped with a session identifier, ID, of the first device.

At step 708, the method 700 comprises initiating at least one task associated with the first device using the received private data. In some examples, initiating the at least one task may include executing any of the applications such as, but are not limited to, a camera, a microphone, a speaker, a display application, a streaming application, a navigation application, a gaming application, and so on, on the second device.

In some examples, the method 700 may comprise transmitting, to the computing device, at least one of: newly created and modified private data on the second device while the at least one task associated with the first device is being performed on the second device.

In some examples, the method 700 may comprise transmitting, to the computing device, a second request indicating an expiry of the session ID of the first device. In response to the second request, the method may comprise receiving, from the computing device, instructions to remove the private data upon transmitting the second request and removing the private data in a data storage/memory. Upon removing the private data, the method may comprise transmitting, to the computing device, the termination message indicating that the second device has removed the received private data and to terminate a communication session between the second device and the computing device. In some examples, the termination message may further be signed by a cryptographic key embedded in a trusted part of the second device 104 to raise the trustworthiness of the data having been removed from the second device 104.

Fig. 8 is a flowchart illustrating method steps of a method 800 performed by a first device for accessing a second device in a secure environment for at least one time instance. The second device is in communication with a computing device in the secure environment.

At step 802, the method 800 comprises sharing a session identifier, ID, with the second device. The session ID may be a temporary identifier/token provided by the computing device to the first device.

In some examples, prior to the step 802, the method 800 may comprise performing a handshake with the computing device to establish a secure channel between the computing device and the first device. The method may comprise uploading the profile data to the computing device over the secure channel established between the computing device and the first device. After receiving the session ID from the computing device for authentication, the profile data is uploaded to the computing device. In some examples, prior to the step 802, the method may comprise initiating a mutual attestation between a data source dedicated for the first device and the first device via the second device to establish a secure channel between the data source and the first device via the second device. The data source may be controlled by the computing device. The method may comprise uploading the profile data to the data source over the secure channel established between data source and the first device via the second device. The method may further comprise receiving the session ID from the data source via the second device.

In some examples, the session ID may comprise at least one of: a temporary identifier, a token, and a key assigned for the first device to establish a communication session with the second device.

At step 804, the method 800 comprises requesting, based on the shared session ID, the second device to initiate at least one task to be performed on the second device. The at least one task is performed based on reception of private data from the computing device. The private data comprises at least a part of profile data of the first device.

Fig. 9 is an example schematic diagram showing functional modules of a data-sharing manager 250 of a computing device 108. The data-sharing manager 250 is capable of handling data sharing in a secure environment and may be configured to cause performance of the method 600 for handling data sharing in the secure environment (as described above in conjunction with Fig. 6). The data-sharing manager 250 is configured to be in communication with a pool of second devices. A second device is configured to be accessed by a first device for at least one time instance.

The data-sharing manager 250 comprises one or more modules such as an attestation module 902, a data-sharing module 904, a tracking module 906, and a communication module 908.

The attestation module 902 may be adapted to perform a handshake (i.e., mutual attestation) with the second device to establish a secure channel between the second device and the computing device 108. The attestation module 902 may also be adapted to perform a handshake (i.e., mutual attestation) with the first device to establish a secure channel between the first device and the computing device 108. The communication module 908 may be adapted to receive profile data of the first device and/or profile data of an owner/entity associated with the second device. The received profile data may be stored in a database of the computing device 108 or in a data source dedicated for the first device (as described above in conjunction with Figs. 2A and 2B).

The communication module 908 may also be adapted to receive a first request from the second device for private data.

The data-sharing module 904 may be adapted to determine whether the second device is equipped with a session identifier, ID, of the first device. When it has been determined that the second device is equipped with the session ID of the first device, the data-sharing module 904 may enable the communication module 908 to transmit the requested private data to the second device via the established secure channel. The private data may comprise at least a part of the profile data of the first device and/or at least a part of the profile data of the owner associated with the second device.

The communication module 908 may also be adapted to receive at least one of: newly created or modified private data from the second device via the secure channel, when one or more tasks on behalf of the first device are performing on the second device.

The tracking module 906 may be adapted to perform one or more data handling actions to prevent the first and second devices from accessing the private data, when the first or second devices is performing any unauthorized action.

The communication module 908 may also be adapted to transmit a request to the second device to remove the private data, when a communication session has been terminated between the first device and the second device.

Fig. 10 is an example schematic diagram showing a second device 104. The second device 104 is capable of accessing data in a secure environment and may be configured to cause performance of the method 700 for data access in the secure environment. The second device is configured to be in communication with a computing device and to be accessed by a first device for at least one time instance.

According to at least some examples of the present invention, the second device 104 in Fig.

10 comprises one or more modules. These modules may e.g. be a memory 1002, a processor 1004, controlling circuitry 1006, transceiver 1008, an attestation module 1010, and a data- requesting module 1012.

The memory 1002, the processor 1004, the transceiver 1008, the attestation module 1010, and a data-requesting module 1012, as well as the controlling circuitry 1006, may be operatively connected to each other.

The controlling circuitry 1006 may be adapted to control the steps as executed by the second device 104. For example, the controlling circuitry 1006 may be adapted to access data in a secure environment (as described above in conjunction with the method 700 and Fig. 7).

The attestation module 1010 may be adapted to perform a handshake (i.e., a mutual attestation) with the computing device to establish a secure channel between the second device and the computing device.

The transceiver 1008 may be adapted to receive a session identifier, ID, of the first device when the first device initiates accessing of the second device. Upon receiving the session ID of the first device, the data-requesting module 1012 may be adapted to enable the transceiver 1008 to transmit a first request to the computing device. The first request is for private data comprising at least a part of profile data of the first device and/or at least a part of profile data of an owner associated with the second device. The transceiver 1008 may also be adapted to receive the requested private data from the computing device via the secure channel established between the second device and the computing device.

The memory/data storage 1002 may be adapted to store at least one of: the private data, the session ID, and so on.

The data-requesting module 1012 may also be adapted to initiate at least one task associated with the first device using the received private data.

The data-requesting module 1012 may also be adapted to remove the private data and the session ID from the memory 1002, upon receiving a request from the computing device when the session ID has been expired (i.e., disconnection of a communication session between the first device and the second device). The processor 1004 may be adapted to operate in conjunction with the computing device to perform an authentication and authorization procedure to determine whetherthe first device is an authenticated and authorized device to access the second device.

Fig. 11 is an example schematic diagram showing a first device 102. The first device is capable of accessing a second device in a secure environment for at least one time instance and may be configured to cause performance of the method 800 for accessing the second device in the secure environment for the at least one time instance. The second device is configured to be in communication with a computing device.

According to at least some examples of the present invention, the first device 102 in Fig. 11 comprises one or more modules. These modules may e.g. be a memory 1102, a processor 1104, a controlling circuitry 1106, a transceiver 1108, an attestation module 1110, a data- uploading module 1112, and an accessing module 1114. The controlling circuitry 1106, may in some examples be adapted to control the above mentioned modules.

The memory 1102, the processor 1104, the transceiver 1108, the attestation module 1110, the data-uploading module 1112, and the accessing module 1114, as well as the controlling circuitry 1106, may be operatively connected to each other.

The controlling circuitry 1116 may be adapted to control the steps as executed by the first device. For example, the controlling circuitry 1116 may be adapted to access the second device in the secure environment for the at least one time instance (as described above in conjunction with the method 800 and Fig. 8).

The attestation module 1110 may be adapted to perform a handshake (i.e., a mutual attestation) with the computing device to establish a secure channel between the first device and the computing device.

The data-uploading module 1112 may be adapted to enable the transceiver 1108 to upload profile data to the computing device via the secure channel established between the first device and the computing device. The data-uploading module 1112 may also adapted to enable the transceiver 1108 to upload the profile data to the computing device via the second device. The transceiver 1108 may also be adapted to receive a session identifier, ID, from the computing device and share the received session ID with the second device.

The accessing module 1114 may be adapted to request, based on the shared session ID, the second device to initiate at least one task to be performed on the second device. The at least one task may be performed on the second device based on private data provided by the computing device. The private data may comprise at least a part of the profile data of the first device.

The processor 1114 may be adapted to monitor the at least one task performed on the second device.

The memory 1102 may be adapted to store at least one of: the profile data, the session ID, and so on.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors, DSPs, special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, RAM, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the disclosure.

Fig. 12 illustrates an example computing environment 1200 implementing methods, a computing device, a second device, and a first device, as described in Figs. 6-11. As depicted in Fig. 12, the computing environment 1200 comprises at least one data processing module 1206 that is equipped with a control module 1202 and an Arithmetic Logic Unit, ALU, 1204, a plurality of networking devices 1208 and a plurality Input output, I/O devices 1210, a memory 1212, a storage 1214. The data processing module 1206 may be responsible for implementing the methods described in Figs. 6-8. For example, the data processing module 1206 may in some embodiments be equivalent to the data-sharing manager of the computing device (as described above in conjunction with Fig. 9) and to the controlling circuitry of the second and first devices (as described above in conjunction with Figs. 10 and 11). The data processing module 1206 is capable of executing software instructions stored in memory 1212. The data processing module 1206 receives commands from the control module 1202 in order to perform its processing. Further, any logical and arithmetic operations involved in the execution of the instructions are computed with the help of the ALU 1204.

The computer program is loadable into the data processing module 1206, which may, for example, be comprised in an electronic apparatus (such as the computing device, the first and second devices). When loaded into the data processing module 1206, the computer program may be stored in the memory 1212 associated with or comprised in the data processing module 1206. According to some examples, the computer program may, when loaded into and run by the data processing module 1206, cause execution of method steps according to, for example, any of the methods illustrated in Figs. 6-8, or otherwise described herein.

The overall computing environment 1200 may be composed of multiple homogeneous and/or heterogeneous cores, multiple CPUs of different kinds, special media and other accelerators. Further, the plurality of data processing modules 1206 may be located on a single chip or over multiple chips. The algorithm comprising of instructions and codes required for the implementation are stored in either the memory 1212 or the storage 1214 or both. At the time of execution, the instructions may be fetched from the corresponding memory 1212 and/or storage 1214, and executed by the data processing module 1206. In case of any hardware implementations various networking devices 1208 or external I/O devices 1210 may be connected to the computing environment to support the implementation through the networking devices 1208 and the I/O devices 1210.

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in Fig. 12 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

1. A method (600) performed by a computing device (108) for data sharing in a secure environment (106), the computing device (108) being in communication with a second device (104), the second device (104) being configured to be accessed by a first device (102) for at least one time instance, the method (600) comprising:

- performing (602) a handshake with the second device (104) to establish a secure channel between the second device (104) and the computing device (108);

- receiving (604), from the second device (104) via the established secure channel, a first request for private data;

- determining (606) whether the second device (104) is equipped with a session identifier, ID, of the first device (102), upon receiving the first request; and

- when it has been determined that the second device (104) is equipped with the session ID of the first device (102), transmitting (608) the requested private data to the second device (104) via the established secure channel, said private data comprising at least a part of profile data of the first device (102) and being adapted for performing at least one task associated with the first device (102) on the second device (104).

2. The method (600) according to claim 1, further comprising: uploading, through at least one of the first device (102) or the second device (104), at least one configuration data into the second device (104) of the first device (102), wherein the configuration data comprises the private data configured in the first device through at least one of the user of the first device (102), the second device (104) or user of the second device (104).

3. The method (600) according to claim any of the preceding claims, further comprising:

- receiving (610), from the second device (104) via the secure channel established between the second device (104) and the computing device (108), at least one of: newly created or modified private data on the second device (104) while the at least one task associated with the first device (102) is being performed on the second device (104), wherein at least one of: newly created or modified private data on the second device (104) is identified according to an update in a key- value data shared through the second device (104), wherein the key represents an update in the private data and the value represents the private data .

4. The method (600) according to any of the preceding claims, further comprising:

- requesting (614) the second device (104) to remove the private data, upon expiration or revocation of the session ID of the first device (102) equipped by the second device (104).

5. The method (600) according to any of preceding claims, further comprising:

- monitoring information related to the first device (102) while the at least one task associated with the first device (102) being performed on the second device (104);

- monitoring, via a log and analyse instance, information related to the second device (104) while the at least one task associated with the first device (102) is being performed on the second device (104), wherein the log and analyse instance provide information about traffic of: the private data exchanged by the second device and computing device, the private data requested by the second device and the corresponding task the private data is requested for;

- determining whether the first device (102) or the second device (104) is performing any unauthorized action, based on evaluation of the monitored information related to the first device (102) and the second device (104); and

- performing (612) one or more data handling actions to prevent the first device (102) or the second device (104) from performing any unauthorized action, when it has been determined that the first device (102) or the second device (104) is performing any unauthorized action.

6. The method (600) according to claim 5, wherein the information related to the first device (102) identifies at least one of: an amount of private data accessed from the second device (104), and whether the at least one task from the one or more tasks is the task requested by the first device and is to be performed on the second device, wherein the information related to the second device (104) identifies at least one of: an amount of private data and a type of private data requested or used by the second device (104) and a frequency associated with generation of requests from the second device (104) for the private data.

7. The method (600) according to any of claims 5-6, wherein the unauthorized action comprises at least one of:

- requesting for the private data that is not relevant for the at least one task of the first device (102), said at least one task is being performed on the second device (104); and

- requesting for the private data for performing the at least one task that is unauthorized to perform on the second device (104) and

- requesting for performing the at least one task manipulating the private data that is unauthorized to perform on the second device.

8. The method (600) according to any of claims 5-7, wherein performing the one or more data handling actions comprises one or more of:

- terminating transmission of the private data to the second device (104);

- transmitting an indication to the second device (104) to terminate the at least one task being performed on the second device (104); and

- transmitting an indication to the second device (104) or the first device (102) to disconnect a session established between the second device (104) and the first device (102).

9. The method (600) according to any of the preceding claims, further comprising:

- receiving the profile data of the first device (102);

- storing the profile data in a database (260) or a data source (270a) among a plurality of data sources (270a-270n), said data source (270a) being dedicated for the first device (102); and

- communicating the session ID to the first device (102), wherein the session ID is shared between the first device (102) and the second device (104) and used to determine whether the first device (102) is an authenticated and authorized device to access the second device (104), wherein the session ID is used to identify an access of the private data allowed to the second device.

10. The method (600) according to claim 9, wherein the step of receiving the profile data of the first device (102) comprises:

- performing a handshake with the first device (102) to establish a secure channel between the first device (102) and the computing device (108); and

- receiving, from the first device (102), the profile data via the secure channel established between the first device (102) and the computing device (108).

11. The method (600) according to any of claims 9-10, wherein the step of receiving the profile data of the first device (102) comprises:

- receiving the profile data of the first device (102) through the second device (104), when the first device (102) is configured to communicate with the computing device (108) through the second device (104).

12. The method (600) according to any of the preceding claims, wherein the step (608) of transmitting the requested private data to the second device (104) comprises:

- identifying the at least one task to be performed on the second device (104), said at least one task being associated with the first device (102);

- determining whether the requested private data is relevant for performing the identified at least one task on the second device (104);

- when it has been determined that the requested private data is relevant for performing the at least one task, verifying whether the second device (104) is an authenticated and authorized device to receive the requested private data; and

- upon verifyingthat the second device is the authenticated and authorized device, transmitting the requested private data to the second device (104).

13. The method (600) according to any of the preceding claims, wherein the step (608) of transmitting the requested private data to the second device (104) further comprises: - identifying the first device (102) for which the private data is requested from the second device (104);

- fetching the requested private data associated with the identified first device (102) from the database (260) or the data source (270a) dedicated for the identified first device (102); and

- transmitting the requested private data to the second device (104).

14. The method (600) according to any of the preceding claims, wherein the step (608) of transmitting the requested private data to the second device (104) further comprises:

- dividing the requested private data into a plurality of data chunks, based on the at least one task to be performed on the second device (104); and

- transmitting the plurality of data chunks to the second device (104) sequentially, while the at least one task is being performed on the second device (104).

15. The method (600) accordingto any of claims 4-14, wherein the step (614) of requesting the second device (104) to remove the transmitted private data comprises:

- receiving, from at least one of: the second device (104) and the first device (102), a second request indicating an expiry of the session ID of the first device (102) equipped by the second device (104);

- requesting the second device (104) to remove the transmitted private data upon receiving the second request; and

- optionally receiving, from the second device, an optionally signed confirmation of the removal of the private data.

16. The method (600) according to any of claims 4-15, further comprising:

- receiving a termination message from the second device (104), said termination message indicating that the second device (104) has removed the transmitted private data and indicating to terminate a communication session between the second device (104) and the computing device (108).

17. The method (600) according to any of the preceding claims, wherein the first request received from the second device (104) indicates at least one of: a device for which the private data is requested, an amount of private data, and a type of private data, wherein the private data comprises a profile data of at least one entity operating the second device (104) along with at least the part of the profile data of the first device (102).

18. The method (600) according to any of the preceding claims, wherein the session ID comprises at least one of: a permanent identifier, temporary identifier, a token, and a key assigned by the computing device (108) for the first device (102) to establish a communication session with the second device (104),

19. The method (600) according to claim 18, wherein the session ID comprises an anonymous and temporary ID of the first device 102 allocated for each session between the computing device 108 and the second device 104, and wherein the session ID comprise an ID of the second device 104 shared with the first device 102 and comprise a scan QR code on the second device 104 shared with the computing device 108, either as part of authentication to get token, or as a trigger for the computing device 108 to provide the private data to the second device 104.

20. A method (700) being performed by a second device (104) for data access in a secure environment (106), the second device (104) being in communication with a computing device (108) in the secure environment (106) and accessed by a first device (102) for at least one time instance, the method (1000) comprising:

- performing (702) a handshake with the computing device (108) to establish a secure channel between the second device (104) and the computing device (108);

- transmitting (704), to the computing device (108) via the established secure channel, a first request for private data, said private data comprising at least a part of profile data of the first device (102);

- receiving (706), from the computing device (108) via the established secure channel, the requested private data, when the second device (104) is equipped with a session identifier, ID, of the first device (102); and initiating (708) at least one task associated with the first device (102) using the received private data.

21. The method (700) according to claim 20, further comprising:

- transmitting, to the computing device (108), at least one of: newly created and modified private data on the second device (104) while the at least one task associated with the first device (102) is being performed on the second device (104).

22. The method (700) according to any of claims 20-21, further comprising:

- transmitting, to the computing device (108), a second request indicating an expiry of the session ID of the first device (102);

- receiving, from the computing device (108), instructions to remove the private data upon transmitting the second request;

- removing the private data in a data storage; and

- transmitting, to the computing device (108), a termination message indicating that the second device (104) has removed the received private data and to terminate a communication session between the second device (104) and the computing device (108).

23. The method (700) according to any of claims 20-22, wherein the step (704) is preceded by steps of:

- receiving the session ID from the first device (102), upon connecting with the first device (102);

- verifying, in conjunction with the computing device (108), whether the first device (102) is an authenticated and authorized device to access the second device (104) based on the received session ID; and

- deciding to transmit the first request for the private data, upon verifying that the first device (102) is the authenticated and authorized device to access the second device (104).

24. A method (800) being performed by a first device (102) for accessing a second device (104) in a secure environment (106) for at least one time instance, the second device (104) being in communication with a computing device (108) in the secure environment (106), the method (800) comprising:

- sharing (802) a session identifier, ID, with the second device (104); and

- requesting (804), based on the shared session ID, the second device (104) to initiate at least one task to be performed on the second device (104), wherein the at least one task is performed based on reception of private data from the computing device (108), said private data comprising at least a part of profile data of the first device (102).

25. The method (800) according to claim 24, wherein the step (802) of sharing the session ID with the second device (104) is preceded by steps of:

- performing a handshake with the computing device (108) to establish a secure channel between the computing device (108) and the first device (102);

- uploading the profile data to the computing device (108) over the secure channel established between the computing device (108) and the first device (102); and

- receiving the session ID from the computing device (108).

26. The method (800) according to any of claims 24-25, wherein the step (802) of sharing the session ID with the second device (104) is preceded by steps of:

- initiating a mutual attestation between a data source (270a) dedicated for the first device (102) and the first device (102) via the second device (104) to establish a secure channel between the data source (270a) and the first device (102) via the second device (104), wherein the data source (270a) being controlled by the computing device (108);

- uploading the profile data to the data source (270a) over the secure channel established between data source (270a) and the first device (102) via the second device (104); and

- receiving the session ID from the data source (270a) via the second device (104).

27. The method (800) according to any of claims 24-26, wherein the session ID comprises at least one of: a temporary identifier, a token, and a key assigned for the first device (102) to establish a communication session with the second device (104).

28. A computing device (108) for data sharing in a secure environment (106), the computing device (108) being in communication with a second device (104), the second device (104) being configured to be accessed by a first device (102) for at least one time instance, the computing device (108) being adapted for:

- performing a handshake with the second device (104) to establish a secure channel between the second device (104) and the computing device (108);

- receiving (910), from the second device (104) via the established secure channel, a first request for private data;

- determining whether the second device (104) is equipped with a session identifier, ID, of the first device (102), upon receiving the first request; and

- when it has been determined that the second device (104) is equipped with the session ID of the first device (102), transmitting the requested private data to the second device (104) via the established secure channel, said private data comprising at least a part of profile data of the first device (102) and being adapted for performing at least one task associated with the first device (102) on the second device (104).

29. The computing device (108) according to claim 28, wherein the computing device (108) is further configured to perform the method as defined in any of claims 2-17.

30. A second device (104) for data access in a secure environment (106), the second device (104) being in communication with a computing device (108) in the secure environment (106) and accessed by a first device (102) for at least one time instance, the second device (104) being adapted for: performing a handshake with the computing device (108) to establish a secure channel between the second device (104) and the computing device (108); - transmitting, to the computing device (108) via the established secure channel, a first request for private data, said private data comprising at least a part of profile data of the first device (102);

- receiving, from the computing device (108) via the established secure channel, the requested private data, when the second device (104) is equipped with a session identifier, ID, of the first device (102); and

- initiating the at least one task associated with the first device (102) using the received private data.

31. The second device (104) according to claim 30, wherein the second device (104) is further configured to perform the method as defined in any of claims 19-21.

32. A first device (102) for accessing a second device (104) in a secure environment (106) for at least one time instance, the second device (104) being in communication with a computing device (108) in the secure environment (106), the first device (102) being adapted for:

- sharing a session identifier, ID, with the second device (104); and

- requesting, based on the shared session ID, the second device (104) to initiate at least one task to be performed on the second device (104), wherein the at least one task is performed based on reception of private data from the computing device (108), said private data comprising at least a part of profile data of the first device (102).

33. The first device (102) according to claim 32, wherein the first device (102) is further adapted for performing the method as defined in any of claims 23-25.

34. A data handling system (100) for handling private data in a secure environment (1080, the data handling system (100) comprising: a computing device (108) according to any of claims 28-29; a first device (102) according to any of claims 32-33; and a second device (104) according to any of claims 30-31.

35. A computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions, the computer program is loadable into a data processing unit and configured to cause execution of the method according to any of claims 1 through 27 when the computer program is run by the data processing unit.