Pretty Good Phone Privacy (PGPP) is a new service that aims to keep the location of mobile phone users private whilst preventing potential tracking by stingrays (also known as IMSI catchers) or by the user’s own mobile network provider. Identity and location information is used in many forms and for different purposes in a mobile network. Therefore, any service that modifies identities and location information has an impact on how the network works. In this article, I intend to outline:
- the identity approach of PGPP and its impact;
- the location privacy of PGPP and its side effects; and
- obligations for service providers providing PGPP e.g. lawful interception and emergency calls.
Scalability, legal duties, technical side effects and the impact of PGPP on network operations will all be factors in determining whether PGPP is an attractive service that succeeds with customers. For this analysis the following sources were used:
- INVISV, “What Is Pretty Good Phone Privacy”
- Paul Schmitt, Barath Raghavan, “Pretty Good Phone Privacy”, Usenix (2021)
- Paul Schmitt, Barath Raghavan, “Pretty Good Phone Privacy”, (2020)
The last document has a large overlap with the Usenix paper, therefore we assumed that the Usenix paper takes precedence on the way PGPP is implemented because it was published later.
The main feature of PGPP systems is to protect each user’s identity against tracking on the air and by the mobile operator. In the mobile domain we have several identities and the focus for PGPP is the IMSI (International Mobile Subscriber Identity). In 5G the IMSI was a replaced by the SUPI (Subscription Permanent Identifier), which is basically the IMSI and some additional network information to enable roaming. IMSI and SUPI are both permanent identifiers for the subscription and relate to a user’s SIM card. Neither can change. For the technology purists, we actually have a UICC (Universal Integrated Circuit Card) with a USIM (Universal SIM) application. Strictly speaking, a SIM card is a 2G card and the usage of it is not allowed for 4G or 5G, but everybody refers to a UICC card as a SIM card so we will not break this habit here.
Your phone has, in addition, its own identity and that is called the IMEI (International Mobile Equipment Identity). In terms of tracking on the air interface you can be identified and tracked if any one of these identifiers is used in the plain. When looking at the identity of a subscription we also need to consider the keys that go along with it. Your SIM card and the subscriber database of your mobile operator have a shared key. This shared key is used to derive many further security keys for integrity, confidentiality and authentication.
Based on the available information from the article and Usenix conference, we could conduct three potential approaches of PGPP for identity privacy protection.
- All subscriptions have the same identity and the same key.
- All subscriptions have the same identity and different keys.
- All subscriptions have different random identities and different keys.
From a privacy protection perspective, the first approach is the most effective. Section 4 of the Usenix paper mentions that they chose to set the same permanent identity for all subscriptions. In their trial set-up they state they used identical SUPIs and the same shared keys (section 5.4). Therefore we assumed that this approach was also taken for their commercial offering. This has quite some impact on the internal working of a mobile network, including the following particular challenges.
Air security impact
If we assume that PGPP uses the same key (i.e. scenario (1)) for all its subscriptions, then the key derivation parameters for the security would be nearly the same. The only parameter in the key generation process that we could identify as different was a radio channel parameter. This means that a potential attack might be easier to perform and the risk of brute force attacks increases. In general it is safe to say that the strength of the keys is weaker. This impact would not be the case for approach (2) or (3).
Transferring the trust
PGPP assumes that your mobile operator is not trustworthy and further measures are needed to protect you. There are several snares related to that one. The first is, the user shifts trust from the operator to PGPP (which effectively acts as a Mobile Virtual Network Operator in this context). The second downside is that your operator might still be able to track you through the IMEI. The 5G Access Management Function (AMF) potentially gets this information as part of the Security Mode Command complete message from the phone. The AMF needs to request it from the phone i.e. if your operator wants to track you, an untrustworthy operator might do it this way. Also, some phones are always sending the IMEI.
For PGPP to succeed in maintaining privacy, the IMEI must not be revealed. This might be achieved if PGPP would host the AMF, but then there is the question of how to ensure the user is always directed to the PGPP-enhanced AMF that is supporting PGPP. There are usually many AMFs in a network. If the mobile operator is untrustworthy, why would it forward that user to the PGPP-enhanced AMF instead of just keeping the user at their own AMF?
Roaming impact
It is unlikely that roaming will work with PGPP. The Usenix paper states that roaming would be possible; I disagree. There are several technical challenges which are not that easily resolved, and the paper makes some wrong assumptions. A 5G Session Management Function (SMF) is a 5G Service Based Architecture entity and as such, commonly communicates with other nodes using a REST API, not Diameter. Therefore, using a Diameter Edge Agent will not guarantee roaming interoperability.
Another aspect that has not been considered is how a visited network would ‘know enough’ to be able to charge and secure the air interface for any particular user. If all subscriptions have the same identifier, there is no apparent way for the visited network to differentiate between two users in cases (1) and (3). If the PGPP identity does not even contain the home operator name, the visited network would not even know whom to contact. The 5G concealed identifier has for that purpose network information to enable roaming, but this is missing in PGPP. The visited network would then not be able to obtain the authentication vectors that are required
to set up a secure communication between the network and the mobile phone. You may argue that an operator could potentially disable authentication and confidentiality (at its own risk) but integrity is mandatory per the standards. Without those authentication vectors, there is no data session.
The visited network also would not know how to charge correctly if there are several users with the same identity. This conflicts with the Policy Control Function (PCF) which enforces policies for a user (e.g. what kind of services a user is allowed to use etc). How would the PCF be expected to handle different policies for the same apparent identity?
SMS and voice call impact
There are basically two types of SMS and voice. One is the modern version using IP, and the other is the ‘classical’ version that uses telecommunication protocols. If PGPP is deployed then the modern version for SMS and voice calls will work just like any other data service, but you will not be able to make outgoing classical voice calls or send classical SMS messages (SMS over non-acccess stratum, or NAS). This would require a permanent identifier i.e. (1) and (2) would not work. If (3) is used, then a mapping table is needed in the core network, which would defy the idea of identity privacy coming from your mobile operator.
SIM exhaustion
There is a little counter in your SIM card called the sequence number (SQN) which is used for cryptographic purposes. This counter needs to be in synchronization between the network and the SIM card. Now, if we have a large range of SIM cards with the same
IMSI, then the counter is different for each of them. This will lead to frequent synchronization errors between the subscriber database and the SIM cards.
There is a re-synchronization procedure which fixes this problem by basically jumping ahead, but the counter has a limit. In normal operation this would not be a problem, as such incidences are not that common. However, if you have hundreds of thousands of cards with different counters then the counter jumps will become quite large and a SIM card counter could be exhausted. That would not be a significant risk for smaller PGPP deployments, but it would be an issue if PGPP was used at the scale of a major retail communications provider.
Subscriber database handling issues
For some actions in the mobile network, the subscriber database is contacted e.g. to identify which area to page the user or if the user is travelling abroad. If there are now several subscriptions with identical identifiers, then the databases usually search and when the first match is found it will be used and entries in the rest of the database will be ignored. This is an efficient approach, and whilst there exist some proprietary means to handle this kind of special situation involving duplicate entries they are not standardized and it is not clear that they would solve the issues created by PGPP. Therefore, when such a request is made to the database, there is a high probability that the wrong user will be identified.
Emergency situation location
In an emergency situation you may want to let the responders know where you actually are. If you make an emergency data call using PGPP (understanding that PGPP does not support classic voice calls) then your operator would have several subscription identifiers that are the same, but which each have different locations. Also, the granularity of the location will no longer be very good, as elaborated further below. Contracting emergency services using data calls is also problematic for more general reasons, though we will not go into those more general reasons here.
Fraud risk for mobile operator
The risk of fraud might not concern users attracted to PGPP’s privacy features, but it is vital that mobile operators address this risk. If there is no linkage between the data session and the PGPP gateway authentication, how would the operator know somebody is an authorized user for the data service? The operator may need an additional interface to verify that the user has authenticated to the gateway. The challenge for the operator is to make sure that the user is really going through the right PGPP gateway because once the user has the IP address the user would have then free data. The user may deliberately modify his phone software to avoid this gateway. Of course, there might be special IPs and IP firewalls etc, but still this poses a potential fraud risk.
Inventing the wheel twice
PGPP claims to rectify errors and oversights made by the 3rd Generation Partnership Project (3GPP). Every new generation tries to improve the security compared to the previous generation. 5G includes many improvements to protect against location tracking over the air interface; these privacy enhancements have not been considered by PGPP. If fully deployed and used by the network, these enhancements make many of the features of PGPP obsolete, so long as you can trust your mobile operator.
The air interface no longer uses a permanent identifier, but instead uses several changing temporary identifiers. The PGPP paper seems to assume that the SUPI in 5G is used the same way as the IMSI when this is actually not the case. The creators of PGPP claim there is SUPI-based paging i.e. the permanent identifier is broadcasted. If true, they would be right to observe that the ‘right’ phone numbers are put at risk. However, this possibility was removed by 3GPP in 2018.
Other potential risks, such as insufficient refresh procedures or the potential use of permanent identifiers instead of temporary identifiers were removed. 5G introduces a concealed identifier that replaces the SUPI and supports roaming. For the air interface new temporary short-lived identifiers were introduced to avoid tracking of users. These measures are only effective if the network supports all these features and has a 5G core network, but the risk of a mobile operator failing to satisfy these requirements should be weighed against the risk that PGPP may not be implemented as promised.
A mobile phone needs to be tracked to be able to deliver data and services through the right antenna. PGPP provides location privacy by ‘merging’ several areas where the user might potentially be. Those areas are called Tracking Areas (TA). The Tracking Area List (TAL) is a list of adjacent mobile network cells where the user could be. PGPP generates a TAL list on the fly for each user in the AMF (which would be run by PGPP) by selecting random cells and combining them to a TAL. The reason for choosing that approach is due to the misuse of paging messages, but the bugs that created this weakness has been eliminated, as previously described.
The following diagram uses the map of Finland to illustrate how PGPP might construct a TAL by combining the user’s actual TA (in blue) with a random selection of other TAs (in orange).
PGPP’s merging of areas leads to a diverse range of impacts, including the following.
Connectivity impact
Usually the TAL list contains the area where the user really is and some adjacent areas where the user might be or may soon be. This enables rapid handovers and reachability, even if the phone user is talking whilst seated in a high-speed train. In PGPP those adjacent areas are no longer part of the list. Therefore, if you move fast and have an incoming message, the cell where you are that moment will not send a paging message i.e. you will not get the message. The original TAL area idea is also to avoid frequent area updates. PGPP tested an approach that groups base stations, but that then increases the overall amount of cells that are part of the TAL. In other words, while this then restores some of connectivity, it comes at the cost of substantially increased energy consumption.
Network load impact
Large TALs increase the amount of control traffic in the core network, resulting in more area updates. In their 2020 paper, the authors of PGPP studied the impact of the increased load and its impact on the amount of users that each base station can handle. It was clear that base stations can handle fewer users as tracking areas become larger. A mobile operator would need more base stations to offset the impact of PGPP although this will not improve the quality of service provided to users or the number of users that the operator can serve.
Energy consumption
PGPP requires the TAL list to contain the area where the user is and then some random other areas, making it more likely that an area update will be needed. This creates messages in the network and on the air interface, increasing energy consumption. When there is the need to contact the user for an incoming message, then all the base stations in the tracking area list need to send out a paging message. PGPP means the network would not know which of the areas is where the user really is. Because PGPP seeks to have as large a TAL list as possible in order to improve location privacy, there will be increased energy consumption for paging messages as these areas get larger.
Impact on emergency services
In many countries emergency services can locate phone users via their mobile network. One key parameter is knowing the actual cell where the user is located. PGPP location privacy means that there will be a list of random areas in the country where the user might be. The only way out of this would be for the PGPP operator (who is in control of at least some part of the AMF) and the mobile operator to switch off PGPP for emergency calls. This then poses the question, if the mobile operator can switch off PGPP, what would prevent the mobile operator from switching it off at other times? Part of the supposed purpose of PGPP is to protect users from privacy invasions by mobile operators but there is no obvious way to satisfy the requirement to pass location information to the emergency services without trusting the operators of a network.
Legal aspect
Mobile operators are strictly regulated in most countries. Regulators have recently increased their interest in mobile networks and many new obligations have been imposed upon mobile operators and their partners. This includes mobile operators needing to reveal the location of somebody to law enforcement in response to an authorized request received through the proper channels. Typically, governmental agencies will communicate the phone number, IMEI or IMSI of their target through a dedicated interface for lawful interception. It is the legal duty of mobile operators to provide such interfaces. PGPP would interfere with the mobile operator’s ability to fulfil this duty. The mobile operator would not be able to use the IMSI/SUPI for user identification and also could not provide the location of the user.
If the implementation of PGPP means the mobile operator cannot provide adequate data then the duty to provide the user’s real location and identity may then fall upon the PGPP mobile virtual operator. Such transfers of duty are an emerging aspect of the telecommunication ecosystem. By design, the PGPP system needs to contain the AMF. The AMF is the key node, if one wants to obtain location information about a user. We did not find any suggestion in the PGPP material how to handle this kind of situation or any proposal for how to split the legal responsibilities between the mobile operator and its PGPP partner.
Summary
The problem of tracking users when they move around through their mobile phone and subscription identity is a long-standing problem. PGPP is an attempt to solve it by providing a common identity and enlarging the areas where a user might be. This involves modifying data that is stored in the mobile core network, creating a kind of mobile virtual network operator with very specific functionality. While PGPP would then hide the user’s identity, there are serious limitations that make large-scale deployment of PGPP inefficient and unlikely.
Perhaps the worst paradox is that PGPP assumes mobile operators cannot be trusted but operators would need to actively support PGPP to make it work. A truly hostile operator has the means to prevent the usage of PGPP. Even if you assume such a relationship can be made viable, perhaps by governments forcing it upon operators, those governments would still need to explain why they felt the businesses providing PGPP were inherently more trustworthy than existing mobile operators.
Many of privacy threats tackled by PGPP have already been addressed by improvements in the air security of 5G and the introduction of additional concealed and temporary identifiers. A mobile operator that deploys all 5G functionalities will have made most features of PGPP redundant. This is a preferable way to deliver user privacy because of PGPP’s negative impact on the performance on the network and the user’s data connection.
