Every mobile phone, more specifically the USIM within, holds a permanent indentity that is used for authentication towards the network. It is a globally unique number that is comprised of multiple parts that identify the home network operator and the individual subscriber, as shown below. In previous mobile generations, this was known as the International Mobile Subscriber Identity (IMSI). As of 3GPP Release 15, which is the first official 5G release, there is the concept of a Subscription Permanent Identifier (SUPI), which may take the form of either an IMSI or a Network Access Identifier defined in RFC4282.
As outlined in a previous post, certain attributes initially need to be transferred to the network in the clear to establish a security context used to protect subsequent message exchanges. One of them is the SUPI, which is a rather sensitive piece of information that shouldn't be revealed publicly, since it opens up several potential scenarios attackers may use to compromise security and privacy, e.g.:
What a malicious actor or law enforcement will do, is to set up a false base station ("IMSI catcher") for mobile phones to connect to. In 4G this attach procedure usually includes a subscriber's Globally Unique Temporary UE Identity (GUTI) which --as the name suggests-- is a temporary ID introduced to avoid revealing the IMSI over the air. However, if the UE does not hold a GUTI from a previous connection, the IMSI is sent instead. Furthermore, the network may also request the permanent identity by issuing an Identity Request to which the UE responds with an Identity Response containing the IMSI. This is defined as a recovery procedure for when the network is unable to recover the IMSI by means of a GUTI (c.f. TS 33.401).
5G introduces the notion of asymmetric cryptography to protect the SUPI when being sent over the air. Mobile operators may provision the USIM of their subscribers with a home network public key that is used to conceal the SUPI. Depending on the exact configuration, either the USIM itself or the ME will encrypt the SUPI before being sent. The result is called Subscription Concealed Identifier (SUCI, pronouned "Sushi"). Since the raw public key is not used for encryption directly, but as an input to the ECIES scheme, the SUCI is guarenteed to be fresh (pun intended), i.e. different every time it is computed. On the network side, the newly defined Subscription Identifier De-concealing Function (SIDF) is responsible for decrypting the SUCI before the authentication procedure continues. Note that the visited network will still receive the unencrypted SUPI within a confirmation message by the home network, but this only happens iff authentication was successful. Subsequently, the visited network may also send the SUPI to the home network straightaway, e.g. when performing re-authentication.
As shown below, the complete SUCI consists of quite a bit more information than just the permanent subscription identifier. The home network information is required by the visitied network to route the SUCI to the correct roaming partner. A routing indicator may be used by the home network operator to distinguish between different UDM instances the SUCI is routed to. The protection scheme ID indicates which crypto profile was used by the UE to conceal a particular SUCI, so that the SIDF can successfully recover the plaintext SUPI. The home network public key ID enables operators to use multiple public keys for SUCI concealment. Finally, the scheme output is actually the only confidential part, which is computed by encrypting the MSIN in case of an IMSI-type SUPI or the username in case of a NAI-type SUPI.
By use of this mechanism, 5G ensures that the network attach procedure will always carry the UE's permanent identifier in an encrypted manner and only the home network operator is able to decrypt it. In fact, there is no need to reveal this information over the air ever, since the abovementioned Identity Response no longer includes the SUPI either, but the SUCI.
The bad news: SUPI concealment is an optional feature, meaning it's on the home network operator to decide whether or not to enable it. Moreover, the industry doesn't start off with a clean slate. 2G, 3G, and 4G technology is still widely deployed and presumably will be for years to come. As long as mobile phones attempt to connect to earlier generations as well, there's no guarantee the IMSI will not be revealed over the air. Because of that, I believe there is an opportunity for mobile OS vendors, such as Apple and Google, to cater to security-savvy users by introducing a simple configuration option that would allow to disable individual radio technologies, thereby preventing many weaknesses that arise due to nasty bidding-down attacks.