METHOD AND SYSTEM FOR AUTHENTICATING USERS OF MOBILE COMMUNICATION DEVICES THROUGH MOBILITY TRACES

Abstract

A method and system for user authentication through mobility traces comprising: retrieving and processing (401, 411) data records stored in a network events database (14), the data records comprising data of one or more interactions (101) of the user with at least one network element (12) through a mobile device (11) of the user, a timestamp (T) associated with the recorded interactions, a unique identifier of the mobile device (11), a unique identifier of the user and a unique identifier of the network element (12); computing (103) at least one network interaction track, NIT, by using the retrieved data; using the at least one computed NIT (402, 412) to obtain an authentication result, e.g., based on a computed authentication probability (P.sub.i), indicating either a success or a failure of the user authentication to be returned to a third-party service provider (21) requesting the user authentication status check (202, 302).

Claims

1. A method for authenticating users of mobile communication devices through mobility traces, comprising the following steps: recording one or more interactions (101) of a user with at least one network element (12) through a mobile device (11) of the user subscribed in a network service provider (13); characterized by further comprising the following steps: recording, by the at least one network element (12), a timestamp (T), associated with the recorded interactions, a unique identifier of the mobile device (11), a unique identifier of the user and a unique identifier of the network element (12); by using all the data recorded (102) in the previous steps, computing (103) a network interaction track, NIT, by the network service provider (13); by using the computed NIT, obtaining at the network service provider (13) an authentication result indicating either a success or a failure of the user authentication.

2. The method according to claim 1, further comprising sending an authentication status check request (202, 302) to the network service provider (13) from a third-party service provider (21) to which the user is asking access (201, 301) through the mobile device (11), the authentication status check request (202, 302) comprising the user identifier and the timestamp (T) for which the authentication status is requested to be checked, and sending the authentication result from the network service provider (13) to the third-party service provider (21).

3. The method according to claim 2, wherein the authentication status check request (202, 302) further comprises an accuracy parameter, the accuracy parameter being provided by the third-party service provider (21) or negotiated between the network provider (13) and the third-party service provider (21).

4. The method according to claim 2, wherein the authentication status check request (202, 302) further comprises a user authentication request mode selected from single authentication and continuous authentication.

5. The method according to claim 4, wherein, if the user authentication request mode selected is continuous authentication, the authentication status check request (302) further comprises an authentication time period, and wherein the authentication result is obtained by the network service provider (13) and sent to the third-party service provider (21) periodically for every authentication time period until an end of the user authentication request (304) is received from the third-party service provider (21) at the network service provider (13).

6. The method according to claim 5, wherein computing (103) the NIT by the network service provider (13) comprises generating a regular NIT (402) at a time instant t=T, being T the timestamp, and generating at least one temporary NIT (412) at a next time t′=T+M, being M the authentication time period, and wherein obtaining the authentication result by the network service provider (13) comprises comparing the at least one temporary NIT (412) with the regular NIT (402) generated for the same user to detect anomalies (413).

7. The method according to claim 5, wherein the anomalies (413) are detected by using similarity techniques or machine-learning techniques and the authentication result is an authentication probability (P.sub.i) computed based on the anomalies (413) and returned to the third-party service provider (21).

8. The method according to claim 1, wherein the unique identifier of the user is based on an identifier of a SIM card active in the mobile device (11).

9. The method according to claim 1, wherein the recorded interactions are turning on/off the mobile device (11), making/receiving a call in the mobile device (11), location change of the network element (12), technology change of the mobile communication, request to data access via the mobile communication technology, SMS sending/receiving, or network ping exchange for alive confirmation.

10. A system for authenticating users of mobile communication devices through mobility traces, characterized by comprising a server of a network service provider (13) to which a user is subscribed, the server being configured to: retrieve and process (401, 411) data records stored in a network events database (14), the data records comprising data of one or more interactions (101) of the user with at least one network element (12) through a mobile device (11) of the user, a timestamp (T) associated with the recorded interactions, a unique identifier of the mobile device (11), a unique identifier of the user and a unique identifier of the network element (12); compute (103) at least one network interaction track, NIT, by using the retrieved data; obtain an authentication result indicating either a success or a failure of the user authentication based on the at least one computed NIT.

11. The system according to claim 10, further comprising an application programming interface (415) interfacing the server of the network service provider (13) with a third-party service (21), the application programming interface (415) configured to receive an authentication status check request (202, 302) from the third-party service provider (21), the authentication status check request (202, 302) comprising the user identifier and the timestamp (T) for which the authentication status is requested to be checked.

12. The system according to claim 11, further comprising a database (403) for storing the at least one NIT computed by the server and wherein the server is configured to generate a regular NIT (402) at a time instant t=T, being T the timestamp and the regular NIT (402) generated by using the data retrieved from the network events database (14) associated with the timestamp (T) for which the authentication status is requested to be checked.

13. The system according to claim 12, wherein the authentication status check request (302) further comprises an authentication time period (M) and wherein the server is configured to generate at least one temporary NIT (412) at a next time t′=T+M, being M the authentication time period, and wherein the authentication result is obtained by comparing the at least one temporary NIT (412) with the regular NIT (402) generated for the same user to detect anomalies (413), and wherein the server is configured to compute an authentication probability (P.sub.i) based on the anomalies (413) and return the the authentication result based on the authentication probability (P.sub.i) to the third-party service provider (21) through the application programming interface (415).

14. The system according to claim 10, wherein the network element (12) is an access point of a wireless communication network.

15. The system according to claim 10, wherein the mobile device (11) is a mobile phone, a tablet or a notebook.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0046] For the purpose of aiding the understanding of the characteristics of the invention, according to a preferred practical embodiment thereof and in order to complement this description, the following Figures are attached as an integral part thereof, having an illustrative and non-limiting character:

[0047] FIG. 1 shows a time diagram of a sample interaction between a mobile device and network elements.

[0048] FIG. 2 shows a time diagram of a service access and authorization/denegation, according to a possible embodiment of the invention.

[0049] FIG. 3 shows a time diagram of a service access over time and authorization/denegation, according to another possible embodiment of the invention.

[0050] FIG. 4 a schematic diagram of the system architecture for authentication through mobility traces, according to a preferred embodiment of the invention.

DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

[0051] The embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, devices, systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.

[0052] A preferred embodiment of the invention relates to a system implementing a method of user authentication, which may be continuous(-time) or single(-use) authentication, through mobility traces.

[0053] An example timeline for possible implementations of the proposed method is reported in FIGS. 1-3. FIG. 1 reports a possible implementation of a user interacting with network elements, which report to the proper service in the provider's network each interaction, specifying the timestamp t of the interaction, as well as all the required parameters. The service is hence collecting interactions into the user's trace, periodically extracting the user fingerprint, and checking for anomalies.

[0054] FIG. 1 shows a mobile device (11), e.g., a mobile phone, a tablet, a notebook, etc., engaged to a network element (12), e.g., any Access Point of a wireless communication network, through which the user of the mobile device (11) is provided with network services of a network provider (13). A set of three elements is defined to be used as basis of the proposed authentication system: [0055] A mobile device (11), on which a specific application is installed; [0056] A SIM card, active in the mobile device (11); [0057] A user operating the mobile device (11).

[0058] The mobile device (11) is identified by the specific instance of the application it is running. The SIM card is unique and associated to a specific physical person: the user. The user is identified by the pattern of their interactions with specific network elements (timestamp of the interaction, kind of interaction, network element with which the interaction happened).

[0059] Whenever a user authentication is requested for the user, a check is performed on the three elements. If all the elements are recognized and match the user profile created and stored in the backend of the authentication service, the user is authenticated. Otherwise, the user is not authenticated.

[0060] In a possible implementation, as shown in FIG. 1, a user is interacting through a mobile device (11) with network elements (12), which in turn reports to the proper service in the network provider (13), which has already access to a track of the required information with the state-of-the-art systems in order to manage the network functioning and provide the user with network services, keeps track of any user interaction (101) with any network element (12) in a database, building or computing (103) a Network Interaction Track (NIT) as an array/record of the following information received (102) for each network interaction (101) of a user: [0061] A unique identifier of the information record, which may be a function of the—unique—identifier of the SIM card. [0062] An identifier of the mobile device (11), through the instance of the application running there. [0063] A timestamp (t) of the network interaction. [0064] A unique identifier of the network element which the user is interacting with. Note that this information is used to estimate the user location. As an alternative, the user location may be estimated more precisely, adding information also on the signal strength and/or triangulating the signal. Studies have shown as the simple network element identifier represents a strong enough measurement for the user unique identification, but further elements (e.g., signal strength and/or triangulation, etc.) may be added to make the measurement more precise and the error probability lower. [0065] The type of the interaction (101), e.g., turn on/off the phone, making/receiving a call, location change, i.e., tower change, technology change, i.e., shifting between 2G, 3G, 4G, etc., request to data access via 2G, 3G, 4G, SMS sending/receiving, network ping exchange for alive confirmation, etc. Note that only the type of interaction is relevant and hence tracked, not the activity content (e.g., SMS transmission, not the SMS content). This allows to guarantee the user privacy in accordance with the international legislation on data processing and treatment.

[0066] Therefore, the provider (13) does not need to collect any other information for the said user, beyond what is collecting and processing already to provide said user with the communication services said user contracted the operator.

[0067] In a possible implementation of the proposed solution, the array of NITs of a user is automatically analyzed to extract a spatiotemporal fingerprint for the corresponding user with a frequency that may be set by the system manager, e.g., daily.

[0068] The user authentication in FIG. 1 consists only of collecting interactions into the user's trace, periodically extracting the user fingerprint, and checking for anomalies.

[0069] In another possible implementation, shown in FIG. 2: [0070] i. a third-party (21), e.g., a bank service, is configured to ask the network provider (13) for an authentication check (202) of a user asking access (201) from his/her mobile device (11) to the service of the third-party (21); for the authentication check (202) requested by the third-party (21), the user identifier and an accuracy parameter, which may be a percentage of accuracy or a time interval (T), are specified; [0071] ii. the network provider (13) checks (203) the profile of the selected user and identifies if any change in the track or NIT of the user interaction pattern, mobile device and SIM card has happened, over the specified time interval or respecting the specified accuracy; [0072] iii. then the network provider (13) replies to the third-party (21) with an authentication result indication (204) of success or failure (OK/NOK) for the specified user.

[0073] In a further possible implementation, shown in FIG. 3, the network provider (13) constantly monitors (303) the NIT of users in order to detect anomalies and signal them to a third-party (21) providing a service, e.g., bank service, to which users are asking access (301) from their mobile devices (11). As soon as an anomaly is detected, the third-party (21) requesting said continuous authentication check (302) is notified, to guarantee a minimum time response. In the case an anomaly is detected, the third-party (21) sends an end of the request (304) and may ask a new confirmation of some kind to the user.

[0074] In the embodiments of FIGS. 2 and 3, the third-party (21) is the one in charge of sending a request (202, 302) to the network service provider (13) in order to check the authentication status of a user. FIG. 2 particularly shows a possible implementation of a scenario where the third-party (21) requests a one-time authentication, this scenario may reflect services needing single authentications, like door opening, operation authorization, etc. As an alternative, the third-party (21) may request a continuous time authentication over a specified time window, or until an end is specified, as shown in FIG. 3; this scenario may reflect services needing a continuous authentication over the usage period, like renting a scooter/bicycle/motorcycle/vehicle/van, etc.

[0075] The request specifies a user identifier, a time frame (T) over which the track is to be checked for authenticity and the required accuracy. The user track is just checked as specified and an answer is returned to the third-party.

[0076] The accuracy parameter may be negotiated between the network provider (13) and the third-party (21), on the basis of the third-party needs: for example, a higher accuracy or a check over a longer period translates to higher computational complexity for the network operator, which may charge a higher fee for that. At the same time, the third-party (21) may require different accuracy levels for different kinds of operations, depending on their criticality.

[0077] According to a preferred embodiment, a possible architecture implementing the described method is shown in FIG. 4. In particular, in this implementation example, a user U.sub.i normally interacts with the mobile network through a mobile device (11) as usual. The interactions are recorded by the, one or more, network element(s) (12) with which the mobile device (11) is interacting and are stored in a database (14) of network events with a first set frequency f.sub.1. Recorded interactions may include, but are not limited to, turning on/off the phone, making/receiving a call, location change, i.e., tower change, technology change, i.e., shifting between 2G, 3G, 4G, etc., request to data access via 2G, 3G, 4G, SMS sending/receiving, network ping exchange for alive confirmation, etc. These interactions are recorded together with the timestamp (T) and unique identifiers of the: i) mobile device (11), ii) user based on the SIM card identifier, and iii) network element. With a second set frequency f.sub.2>f.sub.1, data in the network element database (14) are processed (401) to generate a regular NIT (402), which is stored into a NIT database (403) in the network.

[0078] At any time given by the timestamp T, a third-party service (21) may request an authentication status for a specific user U.sub.i, by specifying the user's identifier, e.g., SIM Card identifier (SIM.sub.i), and a user authentication request mode (M) selected from i) single authentication (M=0) or ii) continuous authentication, specifying an authentication period in the case (M>0 for an authentication executed every M seconds until a stop message is received by the third-party service). In this case, the application programming interface or API (415), interfacing the proposed user authentication service implemented at the network service provider (13) with the third-party service (21), triggers a user authentication request (416) and eventually a following one at a next time T+M, if M>0). The request (416) triggers a data retriever from the database (14) of network events to fetch and process (411) the latest data for the specified user U.sub.i. A temporary NIT (412) is hence computed for the user a granularity or accuracy of the temporary NIT (412) may also be specified by the third-party service (21) or previously agreed between the network provider (13) and the third-party service (21)—as specified above—, and compared with the regular NIT (402) generated for the same user U.sub.i. On the basis of the similarity, an authentication probability (P.sub.i) is computed and returned to the third-party service (21). Similarity here can be computed using simple techniques such as cosine similarity between the two, regular and temporary, NITs (402, 412), considered respectively as historical and temporary spatio-temporal vectors of the user under examination. Also, more advanced statistical methods based on machine-learning principles can be used, to train a model per user based on their produced (historical) NITs, and then anomalies (413) can be detected by inferring if the temporary NIT is satisfying the trained model or not.

[0079] In the case of continuous authentication, mode M>0, each subsequent triggered authentication request triggers a new one after M seconds, while an eventual stop message from the third-party service (21) removes the following queued authentication request so that no further ones are generated.

[0080] Special situations may prevent an authentic user to be authenticated by the proposed system, e.g., traveling to another place (for tourism, business, etc.), or moving, or performing extra-ordinary activities, having to replace the SIM card and/or the mobile device, etc. Depending on the selected time interval and accuracy level, a short alteration of the user routine may or may not be detected as a change in the user profile. In a possible implementation, exceptions may be preemptively asked by the user, knowing a change is going to happen. As an alternative, these exceptions can be detected by the system and an alert may be triggered to the third-party service suggesting a new authentication request is needed from the user. These exceptions may include, for instance, traveling outside their standard mobility pattern, altering their fingerprint, resulting in a failure to authenticate. If the user asks for an exception, an alternative authentication method may be used for the exception duration. If the user does not ask for the exception, when the system detects it, the third-party service is alerted about the anomaly so that the third-party service can ask for further confirmation by the user and/or proceed with an alternative authentication method, eventually invasive for the user (i.e., involving direct and active user interaction), but just covering the exception duration.

[0081] A user changing his/her SIM card and/or mobile device will naturally lose their ability to be authenticated by the system for as long as a new fingerprint is generated in the system which is stable enough to result in the accuracy required by the corresponding third-party requesting the authentication. As such, a user knowing in advance they are going to change the SIM card and/or mobile device may agree on an exception for the authentication mechanism with the third-party, e.g., two-factor authentication, similarly to above. If the user is not asking for the exception in advance, again, the system can detect the anomaly and trigger a signaling to the third-party service, similarly to above. The third-party service may then ask for alternative authentication methods. Still, these exceptions are only valid for specific cases, while, for the rest of the time, the proposed solution offers continuous, seamless authentication.

[0082] Note that in this text, the term “comprises” and its derivations (such as “comprising”, etc.) should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc.