Two-stage anonymization of mobile network subscriber personal information

A two-stage anonymization process is applied to monitored network traffic in which unique user identifiers, such as the MSISDN (Mobile Station International Subscriber Directory Number), are extracted from the traffic and anonymized to generate an ASI (anonymized subscriber identifier). A strictly random RSI (random subscriber identifier) is generated and used to replace the ASI. The RSI is generated upon a first occurrence of an ASI and stored in a lookup table for utilization upon subsequent ASI occurrences. Use of the strictly random RSI enables various studies and analysis of user behavior to be performed at a heightened level of privacy protection as compared with conventional anonymization schemes that do not utilize strictly random identifiers.

BACKGROUND

Communication networks provide services and features to users that are increasingly important and relied upon to meet the demand for connectivity to the world at large. Communication networks, whether voice or data, are designed in view of a multitude of variables that must be carefully weighed and balanced in order to provide reliable and cost effective offerings that are often essential to maintain customer satisfaction. The ability to analyze network activities and manage information gained from the accurate measurement of network traffic characteristics is generally important to ensure successful network operations. However, for reasons of security and privacy, monitored network traffic typically needs to be irreversibly anonymized so that Personally Identifiable Information (PII) about users is not directly or indirectly revealed. While current anonymization methodologies often perform satisfactorily, there are some instances where stronger privacy protection is needed.

SUMMARY

A two-stage anonymization process is applied to monitored network traffic in which unique user identifiers, such as the MSISDN (Mobile Station International Subscriber Directory Number), are extracted from the traffic and anonymized to generate an ASI (anonymized subscriber identifier). A strictly random RSI (random subscriber identifier) is generated and used to replace the ASI. The RSI is generated upon a first occurrence of an ASI and stored in a lookup table for utilization upon subsequent ASI occurrences. Use of the strictly random RSI enables various studies and analyses of user behavior to be performed at a heightened level of privacy protection as compared with conventional anonymization schemes that do not utilize strictly random identifiers.

In various illustrative examples, the ASI is generated by a network probe associated with a network intelligence solution (NIS) arranged for monitoring a mobile communications network such as a GPRS (General Packet Radio Service) network. The ASI is generated by applying a cryptographic hash function such as HMAC-SHA1 (Hash-based Message Authentication Code-Secure Hash Algorithm 1) to the MSISDN twice in succession using two separate keys. The ASI is inserted into GTP (GPRS Tunneling Protocol) traffic and received at the NIS which generates an RSI using a collision-free random code generator. The associated ASI and RSI are stored in an ASI/RSI lookup table so that the RSI can be persisted for subsequent occurrences of the ASI that are received at the NIS. Advantageously, such persistence enables behavioral metrics such as unique user visits to be collected while preserving heightened privacy protections.

The ASI/RSI lookup table can be cleaned-up by an automated process that loops through the table on a periodic basis to remove inactive ASIs. The RSI may be periodically reset to limit individual RSI persistence by subjecting the RSI to a time-to-live (TTL) value where the association between a given ASI and RSI is deleted when the TTL value is exceeded using an automated process that loops through the lookup table. In this case, a new RSI is generated even when the ASI has been previously seen at the NIS. A management interface can be locally instantiated at the NIS or implemented remotely to provide an administrator with tools to manage various aspects of the two-stage anonymization process. For example, parameters used by the table clean-up and RSI reset procedures can be specified at the management interface, the ASI/RSI table may be periodically saved to persistent storage, and process logging and monitoring functions may be controlled.

Like reference numerals indicate like elements in the drawings. Unless otherwise indicated, elements are not drawn to scale.

DETAILED DESCRIPTION

FIG. 1shows an illustrative mobile communications network environment100that facilitates access to resources by users1051, 2 . . . Nof mobile equipment1101, 2 . . . Nand with which the present arrangement may be implemented. In this example, the resources are web-based resources that are provided from various websites1151, 2 . . . N. Access is implemented, in this illustrative example, via a mobile communications network120that is operatively connected to the websites115and/or other resources via the Internet125. Accordingly, the users105are typically subscribers to a service that operates in whole or part over the mobile communications network120. It is emphasized that the present arrangement is not necessarily limited in applicability to mobile communications network implementations and that other network types that facilitate access to the World Wide Web including local area and wide area networks, PSTNs (Public Switched Telephone Networks), and the like that may incorporate both wired and wireless infrastructure may be utilized in some implementations.

In this illustrative example, the mobile communications network120may be arranged using one of a variety of alternative networking standards such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), GSM/EDGE (Global System for Mobile Communications/Enhanced Data rates for GSM Evolution), CDMA (Code Division Multiple Access), CDMA2000, or other 2.5G, 3G, 3G+, or 4G (2.5thgeneration, 3rdgeneration, 3rdgeneration plus, and 4thgeneration, respectively) wireless standards, and the like.

The mobile equipment110may include any of a variety of conventional electronic devices or information appliances that are typically portable and battery-operated and which may facilitate communications using voice and data. For example, the mobile equipment110can include mobile phones (e.g., non-smart phones having a minimum of 2.5G capability), e-mail appliances, smart phones, PDAs (personal digital assistants), ultra-mobile PCs (personal computers), tablet devices, tablet PCs, handheld game devices, digital media players, digital cameras including still and video cameras, GPS (global positioning system) navigation devices, pagers, electronic devices that are tethered or otherwise coupled to a network access device (e.g., wireless data card, dongle, modem, or other device having similar functionality to provide wireless Internet access to the electronic device) or devices which combine one or more of the features of such devices. Typically, the mobile equipment110will include various capabilities such as the provisioning of a user interface that enables a user105to access the Internet125and browse and selectively interact with web pages that are served by the Web servers115, as representatively indicated by reference numeral130.

The network environment100may also support communications among machine-to-machine (M2M) equipment and facilitate the utilization of various M2M applications. In this case, various instances of peer M2M equipment (representatively indicated by reference numerals145and150) or other infrastructure supporting one or more M2M applications will send and receive traffic over the mobile communications network120and/or the Internet125. In addition to accessing traffic on the mobile communications network120in order to classify web pages and domains in an automated manner, the present arrangement may also be adapted to access M2M traffic traversing the mobile communications network. Accordingly, while the methodology that follows is applicable to an illustrative example in which Internet usage of mobile equipment users is measured, those skilled in the art will appreciate that a similar methodology may be used when M2M equipment is utilized.

A network intelligence solution (NIS)135is also provided in the environment100and operatively coupled to the mobile communications network120, or to a network node thereof (not shown) in order to access traffic that flows through the network or node. In alternative implementations, the NIS135can be remotely located from the mobile communications network120and be operatively coupled to the network, or network node, using a communications link140over which a remote access protocol is implemented. In some instances of remote operation, a buffer (not shown) may be disposed in the mobile communications network120for locally buffering data that is accessed from the remotely located NIS.

It is noted that performing network traffic analysis from a network-centric viewpoint can be particularly advantageous in many scenarios. For example, attempting to collect information at the mobile equipment110can be problematic because such devices are often configured to utilize thin client applications and typically feature streamlined capabilities such as reduced processing power, memory, and storage compared to other devices that are commonly used for web browsing such as PCs. In addition, collecting data at the network advantageously enables data to be aggregated across a number of instances of mobile equipment110, and further reduces intrusiveness and the potential for violation of personal privacy that could result from the installation of monitoring software at the client. The NIS135is described in more detail in the text accompanyingFIGS. 3 and 6below.

FIG. 2shows an illustrative web browsing session which utilizes a protocol such as HTTP (HyperText Transfer Protocol) or SIP (Session Initiation Protocol). In this particular illustrative example, the web browsing session utilizes HTTP which is commonly referred to as a request-response protocol that is commonly utilized to access websites. Access typically consists of file requests2051, 2 . . . Nfor pages or objects from a browser application executing on the mobile equipment110to a website115and corresponding responses2101, 2 . . . Nfrom the website server. Thus, at a high level, the user105interacts with a browser to request, for example, a URL (Uniform Resource Locator) to identify a site of interest, then the browser requests the page from the website115. When receiving the page, the browser parses it to find all of the component objects such as images, sounds, scripts, etc., and then makes requests to download these objects from the website115.

FIG. 3shows details of the NIS135which is arranged, in this illustrative example, to monitor network traffic in the mobile communications network120in order to perform a variety of analyses305. Such analyses305, as respectively indicated by reference numerals310,315,320, and325inFIG. 3, illustratively include monitoring Internet usage by the users105, monitoring user behaviors, generating various reports, and performing other analytical or monitoring functions as may be required. In some implementations, the NIS135will perform deep packet inspection of the monitored traffic in order to facilitate such analyses. It is emphasized that the exemplary analyses shown inFIG. 3are intended to be illustrative and that the number and particular analyses that are utilized in any given application can differ from what are shown.

The NIS135is typically configured as one or more software applications or code sets that are operative on a computing platform such as a server335or distributed computing system. In alternative implementations, the NIS135can be arranged using hardware and/or firmware, or various combinations of hardware, firmware, or software as may be needed to meet the requirements of a particular usage scenario. As shown, network traffic typically in the form of IP (Internet Protocol) packets330flowing through the mobile communications network120, or a node of the network, is captured via a tap340.

FIG. 4shows details of operations that may be performed at the tap340. At a mirror port405conforming to the Gn (i.e., Ethernet) interface in the GPRS protocol, identification and behavioral data410are extracted from GTP (GPRS Tunneling Protocol) traffic at a Gateway GPRS Support Node (GGSN)415along some portion420of the mobile communications network. As shown inFIG. 5, the data410typically includes some form of indirect Personally Identifiable Information (PII)505such as the MSISDN (Mobile Station International Subscriber Directory Number)510associated with mobile equipment110employed by a network user105(FIG. 1), or alternatively, the IMEI (International Mobile Equipment Identity)515, or IMSI (International Mobile Subscriber Identity)520.

Returning toFIG. 4, an irreversible anonymization process425is implemented at an NIS probe430in the first anonymization stage of the present arrangement. The process425applies a cryptographic hash function435, such as the known HMAC-SHA1 hash (Hash-based Message Authentication Code-Secure Hash Algorithm 1) successively to the MSISDN, in this example, using two separate keys440and445, to generate anonymized code referred to here as the anonymized subscriber identifier (ASI)450. The ASI450is inserted into the GTP session data455at the NIS probe430before the data is received at the NIS135, as shown inFIG. 5.

FIG. 6shows the second stage of the present arrangement in which a random subscriber identifier (RSI) is generated at the NIS135. Using an RSI generator605in the NIS135which may be embodied, for example, as a collision free random code generator executing in volatile memory610, an RSI615is implemented as random code which replaces the ASI450received at the NIS135. In this particular example, the ASI450is represented in exemplary hexadecimal form, as shown inFIG. 6by reference numeral620. When the ASI450received at the RSI generator605has not been previously seen (i.e., is unknown), then a new RSI is generated and the associated ASI/RSI pair is written to a lookup table625. The associated RSI is represented in exemplary hexadecimal form by reference numeral630.

The lookup table625will typically be implemented in volatile memory635and will store different ASI/RSI pairs6401, 2 . . . Nwhere the size of the table can vary by implementation. In addition to containing the values of ASI/RSI pairs, in some implementations, the lookup table625can store additional fields of information such as record creation time and last record read time on a per-ASI/RSI pair basis.

When an ASI is received at the RSI generator605that has been seen before and is thus known (i.e., is already present in the ASI/RSI lookup table625), then the RSI associated with that particular ASI is reused. Among other applications, such reuse enables RSI persistence so that reports including metrics such as unique visits, for example, can be generated. The RSI615, whether newly generated by the generator605or persisted from the lookup table625, can be archived in non-volatile memory645such as a hard-disk drive or other stable storage in the form of comma-separated value (CSV) files650, for example.

In some applications, excessive individual RSI persistence may be avoided by limiting the time for which an ASI-RSI association remains valid. Here, an RSI may be assigned a time-to-live (TTL) value that when exceeded will cause the RSI to be deleted from the lookup table625. In this case, when an ASI is received at the RSI generator605, even if previously seen and known, a new RSI will be generated. An automated RSI-reset process can typically be used to periodically loop through the lookup table625and delete the ASI-RSI associations for which the RSI has exceeded its TTL value. For example, old records are selected for deletion using an age calculation in which the “record creation time” field from the ASI/RSI lookup table is compared to the current time. When the calculated age exceeds the defined TTL the relevant records are removed from the table.

The TTL value may be configured to be specifiable in some cases by an administrator or other qualified personnel having access to the NIS135. In a similar manner, an automated table clean-up process may be run periodically to remove inactive ASI entries from the lookup table625. For example, inactive records are selected for deletion using an age calculation in which the “last record time” field from the ASI/RSI lookup table is compared to the current time. When the calculated age exceeds some arbitrary (or administrator-specified) threshold, the records are removed from the table.

An ASI/RSI lookup table “save” functionality may be optionally enabled in order to prevent the loss of ASI-RSI association when the NIS135, or particular processes/applications running on it, are started or restarted. In this case, the ASI/RSI lookup table625is periodically written to an encrypted file655in encrypted non-volatile memory660(such as a hard-disk drive or other stable storage) and then loaded into volatile memory upon startup/restart, as indicated by the arrow665inFIG. 6. A conventional encryption algorithm such as AES-128 (Advanced Encryption Standard using a 128 bit cryptographic key) may be used to perform the encrypted write.

FIG. 7shows an illustrative management interface705exposed by the NIS135to an administrator710, or other qualified personnel, to the RSI generator605. The management interface705provides a set of tools to enable the administrator710to perform a variety of management functions pertaining to the present two-stage anonymization process. An RSI reset function715can be configured to enable the administrator710to specify the value of the TTL in some convenient time unit (e.g., seconds). The RSI reset function715may also allow the administrator to specify the periodicity of the looping of the RSI reset process through the ASI/RSI lookup table625(FIG. 6). A table clean-up function720can be configured to enable the administrator710to specify the threshold age at which inactive ASI entries are removed from the table. The table clean-up function720may also allow the administrator to specify the periodicity of the looping of the table clean-up process through the ASI/RSI lookup table.

A save to encrypted storage function725may enable the administrator710to set an option to allow the ASI/RSI lookup table625to be saved as an encrypted file655to non-volatile memory660(FIG. 6). The administrator may also specify the periodicity of the save to non-volatile memory using the save function725in some cases. Process logging and monitoring functions, respectively indicated by reference numerals730and735, can also be provided by the management interface705to enable the administrator710to specify parameters pertaining to logging and monitoring of the present two-stage anonymization process. A configuration file740may be utilized to store various parameters associated with the two-stage anonymization process and/or the tools included in the management interface705.

FIG. 8shows a flowchart of an illustrative method800for two-stage anonymization of mobile network subscriber personal information. The method800may be implemented, for example, using the elements shown inFIGS. 4,6, and7and described in the accompanying text. The method begins at block805. At block810, GTP traffic flowing across a network or network node is tapped to collect IP packets. At block815, a unique user ID, such as the MSISDN is extracted from the GTP traffic at the NIS probe430. An ASI is generated by application of two successive cryptographic hash functions, such as HMAC-SHA1, to the extracted ID at block820. The ASI is inserted at the NIS probe430into the GTP session data prior to being sent to the NIS135for subsequent processing at block825.

At decision block830, if the ASI received at the RSI generator605in the NIS135has not been seen previously (i.e., is unknown), then a new RSI is generated at block835and the ASI-RSI association is stored in the ASI/RSI lookup table625at block840. If the received ASI is known, then control passes to decision block845where it is determined if the RSI associated with the received ASI has exceeded its TTL. If it has, then a new RSI is generated at block835. If the TTL has not been exceeded, then at block850, the RSI that is associated with the received ASI is persisted from the ASI/RSI lookup table625.

At block855, the RSI is written to non-volatile memory645, for example in one or more CSV files650, for use in subsequent analyses. Such analyses may include those shown inFIG. 3and described in the accompanying text. At block860, the ASI/RSI lookup table can be periodically saved as an encrypted file655in non-volatile memory660. At block865, the automated RSI reset and/or table clean-up processes are performed periodically. At block870, one or more tools can be exposed through the management interface705to enable an administrator, or other qualified personnel to control various parameters used in the present two-stage anonymization process. At block875, the ASI/RSI lookup table can be loaded from non-volatile memory upon startup or restart of a computing platform upon which the two-stage anonymization process executes.

It is noted that the method steps shown at blocks855to875can be performed in a different order from what is shown inFIG. 8. The method ends at block880.