5G/NR

 

 

 

UE IDs

The UE ID in a 5G network is used to uniquely identify the UE and establish secure communication between the UE and the network. The UE ID can be a temporary identifier (SUCI) or a permanent identifier (SUPI), and it is used in various network procedures, such as registration, authentication, and key agreement.

Basically the intended role of UE ID is same in 5G and in other legacy technology (4G, 3G etc), but UE IDs in 5G is extended and enhanced to compensate for various issues / vunerabilities observed in previous technologies.

In this note, I want to talk about what type of new UE IDs are introduced in 5G and how they can handle various issues we faced in previous technology.

Types of UE IDs

There are many different types of UE IDs in 5G. A simple way to check on the type of UE IDs in 5G would be to check on the list of UE IDs used in 5G Registration message which are listed as below. You would see some of the IDs same as in 4G (e.g, IMEI, IMEISV) but most of others are new types introduced in 5G (e.g, SUCI, 5G-GUTI etc)

    SUCI

      SUCI (SUPI Format = IMSI)

        mcc

        mnc

        Routing Indicator (16 bit, 4 digit)

        Protection scheme Id (4 bit)

        Home network public key identifier (8 bit)

        Scheme output (n Bytes)

      SUCI (SUPI Format = Network specific identifier)

        Type of identity (3 bit)

        SUCI NAI (n bytes)

    5G-GUTI

      mcc

      mnc

      AMF Region ID (8 bit)

      AMF Set ID (10 bit)

      AMF Pointer (6 bit)

      5G TMSI (32 bit)

    IMEI

    5G-S-TMSI

      AMF Set ID (10 bit)

      AMF Pointer (6 bit)

      5G - TMSI(32 bit)

    IMEISV

International Mobile Subscriber Identity (IMSI): This is a unique identifier assigned to a mobile device that is used to identify the device and its associated subscription information. The IMSI is typically stored on the SIM card and is used during initial registration and authentication with the mobile network.

Temporary Mobile Subscriber Identity (TMSI): This is a temporary identifier assigned to a mobile device by the network to protect the device's identity during normal operation. The TMSI is used instead of the IMSI to reduce signaling overhead and improve security.

5G Globally Unique Temporary Identity (5G-GUTI): This is a temporary identifier used in 5G networks to identify a mobile device and its associated subscription information. The 5G-GUTI is used instead of the IMSI to protect the device's identity and provide improved security and privacy.

    NOTE : We have GUTI in 4G as well. What is the differeces between 4G GUTI and 5G GUTI ?

    Neither GUTI carries a permanent identity, and neither carries the other kind of identity either. 23.003 builds the 4G GUTI from MCC, MNC, MME Group ID, MME Code and M-TMSI. It builds the 5G GUTI from MCC, MNC, AMF Region ID, AMF Set ID, AMF Pointer and 5G-TMSI. So the real difference is the shape of the network part. 4G points at one MME. 5G points at a region, then a set, then a pointer inside that set. That extra level is what lets an AMF set share load and change members, while the identity the UE holds stays the same.

    The privacy difference sits elsewhere. It is not in the GUTI at all, but in what the UE sends before it has one. 4G sends the IMSI in the clear at that moment. 5G sends a SUCI instead, and the rest of this note is about that message.

International Mobile Equipment Identity (IMEI): This is a unique identifier assigned to a mobile device by the manufacturer. The IMEI is used to identify the device and is used for purposes such as blocking stolen devices from accessing the network.

Subscription Permanent Identifier (SUPI) : This is a unique identifier used to represent a subscriber's permanent identity in a 5G network. It replaces the IMSI used in 4G networks and is designed to provide enhanced privacy and security features.

Subscription Concealed Identifier (SUCI) : This is a temporary identifier used to conceal the subscriber's permanent identity (SUPI) in a 5G network. It is used for authentication and authorization purposes and provides improved security and privacy features compared to the IMSI used in 4G networks.

The main differences among these IDs are the purpose for which they are used and their scope of use. The IMSI and TMSI are primarily used by the network to identify and authenticate the device, while the 5G-GUTI provides improved security and privacy. The IMEI is used by the network to identify the device and may be used for additional purposes such as blocking stolen devices. Each of these IDs has its own unique characteristics and advantages, and their use may vary depending on the specific requirements of the network and the device.

Differences between 4G UE ID and 5G UE ID ?

In general, 5G UE ID is more complex and provides improved security and privacy compared to 4G UE ID. Main reasons behind these differnces comes from the differnces of network architecture and from the motivation for improved security protection. Followings are some of the important differneces between 4G UE ID and 4G UE ID.

Format: 4G UE ID is usually made up of simple information assigned by manufacturer (e.g,IMEI) and network operator(e.g, IMSI). On the other hand, 5G UE ID is a combination of several identifiers, including the 5G-GUTI (5G Globally Unique Temporary Identity) and the 5G-S-TMSI (5G S-Temporary Mobile Subscriber Identity), which are assigned by the network.

Security: 5G UE ID provides enhanced security and privacy compared to 4G UE ID. In 5G networks, the 5G-GUTI is used as a temporary identifier to protect the UE's identity and prevent tracking. Additionally, 5G networks use stronger encryption algorithms than 4G networks, which further enhance security.

    NOTE : An example of security volnerability in 4G is to use IMSI at the early stage of registration process (e.g, before authentication and key agreement). In 5G, SUPI is a counter part to IMSI in previous technology. But in 5G, it is not allowed to use SUPI even before authentication and key agreement. 5G does not allow SUPI (Plain text information). It uses a kind of encrypted version called SUCI

    NOTE : Refer to How SUPI turn into SUCI section for further details on this.

Network Architecture: 5G networks have a different network architecture than 4G networks, which also affects the UE ID. In 5G networks, the UE ID is used to identify the UE and its associated subscription information in a specific network slice, while in 4G networks, the UE ID is used to identify the UE and its associated subscription information in a specific PLMN (Public Land Mobile Network).

Network Services: 5G networks provide new services such as network slicing and edge computing that require the UE to be identified in a specific network slice. In contrast, 4G networks provide services such as voice and data that do not require the same level of UE identification.

A 5G-GUTI and a 4G GUTI are the same 80 bits

The differences listed above are real, but they hide something that matters more in practice. The two identities are the same size and they map onto each other bit for bit. A UE moving from 5GS to E-UTRAN does not request a new identity. It rewrites the one it holds, and 23.003 clause 2.10.2 states the rewrite exactly.

5GS field

E-UTRAN field

How much moves

MCC

MCC

unchanged

MNC

MNC

unchanged

AMF Region ID, 8 bits

MME Group ID, bits 15 down to 8

whole field

AMF Set ID, bits 9 down to 2

MME Group ID, bits 7 down to 0

8 of its 10 bits

AMF Set ID, bits 1 down to 0

MME Code, bits 7 down to 6

the other 2 bits

AMF Pointer, 6 bits

MME Code, bits 5 down to 0

whole field

5G-TMSI, 32 bits

M-TMSI, 32 bits

unchanged

The AMF Set ID is the only field that splits. Its top eight bits finish the MME Group ID and its bottom two open the MME Code.

The reverse direction is the same table read backwards, and both the UE and the network perform it. When a UE moves from E-UTRAN to 5GS it maps its GUTI into a 5G-GUTI before sending it. When a new MME asks an old AMF for the UE context, the AMF maps the GUTI it received back into a 5G-GUTI so that it can find the context it stored.

One shortened form is worth knowing alongside these. The Truncated 5G-S-TMSI is 40 bits, built for RRC Connection Re-Establishment on the control plane for NB-IoT. It takes the n least significant bits of the AMF Set ID, the m least significant bits of the AMF Pointer, and whatever remains of the budget from the 5G-TMSI, which is 40 minus n minus m bits.

  • The interworking identity is not a new identity : a UE crossing between 5GS and E-UTRAN rewrites the identity it already holds. Both sides perform the same mapping, in opposite directions.
  • The AMF Set ID straddles two E-UTRAN fields : eight of its ten bits go to the MME Group ID and two go to the MME Code. It is the only field in the mapping that does not move whole.
  • The TMSI never changes width : 5G-TMSI and M-TMSI are both 32 bits and map straight across, so the temporary part of the identity survives the move untouched.
  • Truncation is configurable, not fixed : the Truncated 5G-S-TMSI has a 40 bit budget, and how it is divided between AMF Set ID, AMF Pointer and 5G-TMSI is chosen rather than specified.

How SUPI turn into SUCI ?

The sections above name SUPI and SUCI and say that one conceals the other. How that concealment actually works is a separate question, and it is the one this section answers. The short version is public key cryptography, with the public key held on the USIM and the private key held in the home network. Everything below follows from that split.

Now I understand a few important things about SUCI as listed below.

  • In 5G, It does not allow SUPI to get directly exchanged over the air since it can easily get snatched by attackers.
  • So they encrypt the SUPI first and transmit the encrypted information over the air. That encrypted version of SUPI is called SUCI.
  • Usually(but not always) this SUCI is transmitted from UE to the network via RegistrationRequest

Now a question arises in my mind. RegistrationRequest is the first NAS message from UE to network and there is no information shared between UE and Network at this point. How can the network decrypt SUCI into SUPI when it recieves it ?

In simple words, the logic is similar to Authentication process. It can be described breifly as below.

  • UE encrypt SUPI using a specifically predefined algorithm known to both UE and the network. UE can select an algorithm from the list as below. (NOTE : you would notice that operate can define their own algorithm if they want. Of course, in that case the operator need to provision the algorithm in USIM and decrypt algorithm in their core network)
    • Null scheme
    • ECIES scheme profile A
    • ECIES scheme profile B
    • Operator-specific protection scheme
  • UE send the encrypted data and a few additional information required for the decoding in RegistrationRequest message (or IdentityInformation if requested by network).
  • Network decrypt the SUCI into plain text using the data and the information contained in the SUCI it recieves (NOTE : This decryption would happen in UDM. SUCI de-consealment is one of UDM functionaligy (23.501-6.2.7)).

Now let's look into this process a little bit more in detail. I am not an expert in encryption. So I would just to write down the overview of the process and do not have detailed knowledge on the encryption and decryption algorithm itself.

Overall signaling flow with SUCI can be illustrated as below.

SUCI call flow across UE, gNB, AMF, AUSF and UDM : the UE encrypts SUPI, sends RegistrationRequest with SUCI, the UDM decrypts it, and RegistrationAccept returns a 5G GUTI

What's happening on UE side ?

Inside of UE, the process of encrypting SUPI into an encrypted information called SUCI. UE can use a specific algorithm from a list of a few different predefined algorith. Following is the illustration of showing the overview of ECIES based encryption algorithm happening in UE.

< 33.501-Figure C.3.2-1: Encryption based on ECIES at UE >

33.501 Figure C.3.2-1, annotated : ECIES encryption at the UE, with red arrows tying the ephemeral public key, ciphertext and MAC tag to the matching SUCI fields

What's happening on Network side ?

Once SUCI is transmitted by UE and received by Network. The network has to decode it notified by UE with information elements : Protection Scheme ID.  Following is the illustration of showing the overview of ECIES based decryption algorithm happening in Network.

< 33.501-Figure C.3.3-1: Decryption based on ECIES at home network >

33.501 Figure C.3.3-1, annotated : ECIES decryption at the home network, with the same SUCI fields entering as inputs and the plaintext block as the output

RegistrationRequest / RegistrationAccept

Once UE encrypted SUPI into SUCI, it would send it to network via RegistrationRequest message at 5GS mobile identity. NOTE : It is not mandatory in terms of 3GPP for UE to use SUCI. It is allowed to use any type of UE IDs shown here. Which type of ID should be used is determined by the requirement from Network Operator and USIM configuration.

    SUCI

      SUCI (SUPI Format = IMSI)

        mcc

        mnc

        Routing Indicator (16 bit, 4 digit)

        Protection scheme Id (4 bit)

        Home network public key identifier (8 bit)

        Scheme output (n Bytes)

      SUCI (SUPI Format = Network specific identifier)

        Type of identity (3 bit)

        SUCI NAI (n bytes)

    5G-GUTI

      mcc

      mnc

      AMF Region ID (8 bit)

      AMF Set ID (10 bit)

      AMF Pointer (6 bit)

      5G TMSI (32 bit)

    IMEI

    5G-S-TMSI

      AMF Set ID (10 bit)

      AMF Pointer (6 bit)

      5G - TMSI(32 bit)

    IMEISV

IdentityRequest

If UE has not used SUCI at RegistrationRequest and Network wants to know of SUCI, Network can request UE to to inform SUCI by sending IdentityRequest with SUCI.

    Bits

    3 2 1

    0 0 1 SUCI

    0 1 0 5G-GUTI

    0 1 1 IMEI

    1 0 0 5G-S-TMSI

    1 0 1 IMEISV

    1 1 0 MAC address

    1 1 1 EUI-64

IdentityResponse with SUCI

If network request UE to send SUCI via IdentityRequest, UE should send IdentityResponse with SUCI in the format shown below. The structure is the same one carried in RegistrationRequest, and that is the point worth noticing. A SUCI has the same shape whichever message carries it.

One rule applies only here. The UE calculates a fresh SUCI for each Identity Response, and it has to limit how often it will do that for a given 5G-GUTI.

    SUCI

      SUCI (SUPI Format = IMSI)

        mcc

        mnc

        Routing Indicator (16 bit, 4 digit)

        Protection scheme Id (4 bit)

        Home network public key identifier (8 bit)

        Scheme output (n Bytes)

      SUCI (SUPI Format = Network specific identifier)

        Type of identity (3 bit)

        SUCI NAI (n bytes)

Quote from 24.501-Table 9.11.3.4.1: 5GS mobile identity information element

Protection scheme identifier (octet 10 bits 1 to 4)

 

Bits

4 3 2 1

0 0 0 0 Null scheme

0 0 0 1 ECIES scheme profile A

0 0 1 0 ECIES scheme profile B

0 0 1 1

to Reserved

1 0 1 1

1 1 0 0

to Operator-specific protection scheme

1 1 1 1

Bits 5-8 of octet 10 are spare and shall be coded as zero.

 

Home network public key identifier (octet 10)

 

The Home network public key identifier (PKI) field is coded as defined in 3GPP TS 23.003. Home network public key identifier shall be coded as "00000000" when Protection scheme identifier is set to "0000" (i.e. Null scheme).

 

Bits

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 Home network PKI value 0

0 0 0 0 0 0 0 1

to Home network PKI value (1-254)

1 1 1 1 1 1 1 0

1 1 1 1 1 1 1 1 Reserved

 

Scheme output (octets 12 to x)

 

The Scheme output field consists of a string of characters with a variable length or hexadecimal digits as specified in 3GPP TS 23.003. If Protection scheme identifier is set to "0000" (i.e. Null scheme), then the Scheme output consists of the MSIN and is coded using BCD coding with each digit of the MSIN coded over 4 bits. If the MSIN includes an odd number of digits, bits 5 to 8 of octet x shall be coded as "1111". If Protection scheme identifier is not "0000" (i.e. ECIES scheme profile A, ECIES scheme profile B or Operator-specific protection scheme), then Scheme output is

coded as hexadecimal digits.

For the SUCI with SUPI format set to "Network specific identifier", the SUCI NAI field contains an NAI constructed as specified in subclause 28.7.3 of 3GPP TS 23.003 and encoded as UTF-8 string.

For the SUCI with SUPI format set to "GCI", the SUCI NAI field contains an NAI constructed as specified in subclause 28.15.5 of 3GPP TS 23.003 and encoded as UTF-8 string.

For the SUCI with SUPI format set to "GLI", the SUCI NAI field contains an NAI constructed as specified in subclause 28.16.5 of 3GPP TS 23.003 and encoded as UTF-8 string.

For the SUCI with SUPI format set to "GLI", the SUCI NAI field contains an NAI constructed as specified in subclause 28.16.5 of 3GPP TS 23.003 and encoded as UTF-8 string.

For the 5G-S-TMSI, bits 5 to 8 of octet 4 are coded as "1111". The coding of the 5G-STMSI is left open for each administration.

NOTE : For the full log with Amarisoft WebGUI, check out this tutorial of Amarisoft TechAcademy.

Example 01 >  SUCI with ECIES-A in RegistrationRequest

Following is an example of SUCI being used in real communication between UE and a Network.  (NOTE : This is an example from Amarisoft Callbox and Amarisoft UEsim)

Amarisoft Callbox and UEsim log, quoted as captured. The highlighted lines are the SUCI.

Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x0 (Plain 5GS NAS message, not security protected)
Message type = 0x41 (Registration request)
5GS registration type:
  Follow-on request bit = 1
  Value = 1 (initial registration)
ngKSI:
  TSC = 0
  NAS key set identifier = 7
5GS mobile identity:
  SUCI
    SUPI format = 0 (IMSI)
    MCC = 001
    MNC = 01  
    Routing indicator = 0
    Protection sheme id = 1 (ECIES scheme profile A)
    Home network public key identifier = 2
    ECC ephemeral public key = 0x13e1feffd2e39a0674efe37ab493bb4bb8a0a338077b28ef294e247709907350
    Ciphertext = 0x294a3f4f32
    MAC tag = 0xd08cab25fd4f58f3
UE security capability:
  0xe0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=0, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)
  0xe0 (5G-IA0=1, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=0, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)

Example 02 > SUCI with Null Algorithm in Identity Response

Following is an example of SUCI being used in real communication between UE and a Network.  (NOTE : This is an example from Amarisoft Callbox and Commerical UE)

Amarisoft Callbox and a commercial UE, quoted as captured. The highlighted lines are the SUCI.

Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x1 (Integrity protected)
Auth code = 0xd6ead5fa
Sequence number = 0x0a
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x0 (Plain 5GS NAS message, not security protected)
Message type = 0x5c (Identity response)
Mobile identity:
  SUCI
    SUPI format = 0 (IMSI)
    MCC = 001
    MNC = 01  
    Routing indicator = 0
    Protection sheme id = 0 (Null scheme)
    Home network public key identifier = 0
    MSIN = 0123456789

What 33.501 Requires of a SUCI

The two examples above are both SUCIs and they behave in opposite ways. One conceals the subscriber and one prints the MSIN in the clear, and both are legal. That is the question this section answers. 33.501 clause 6.12.2 fixes which messages may carry a SUCI, who builds it, which scheme is allowed, and when the concealment may be dropped altogether.

Which messages may carry a SUCI

The section above says that SUCI usually travels in RegistrationRequest. 33.501 is stricter than usually, and it names the complete set. A SUCI appears in exactly three NAS messages and nowhere else.

  • A Registration Request of type initial registration, sent to a PLMN for which the UE does not already hold a 5G-GUTI.
  • An Identity Response, when the network has asked the UE for its permanent identifier. Example 02 above is this case.
  • A De-Registration Request sent during an initial registration for which no Registration Accept with a 5G-GUTI ever arrived.

Read the first one carefully. The condition is not the first registration ever, it is the absence of a 5G-GUTI for that PLMN. A UE that already holds a valid 5G-GUTI registers with the 5G-GUTI, and no SUCI is built at all. That is why a SUCI is rare in a live log and a 5G-GUTI is everywhere.

One sentence removes the obvious loophole. In response to an Identity Request, the UE never sends the SUPI. There is no fallback where the network asks again and receives the plain identity.

Who builds it, and which scheme

Two parties can do the arithmetic, and the USIM decides which. That choice also decides what the ME is allowed to know, which is why it comes before the choice of scheme rather than after it.

Who builds the SUCI, and which protection scheme is used The UE has to build a SUCI Does the USIM say that the USIM itself calculates the SUCI ? The USIM builds it. The ME is given no key, no key identifier and no scheme identifier. 33.501 advises a proprietary scheme here. yes no Are the Home Network Public Key and the priority list provisioned in the USIM ? null-scheme. The scheme output is the MSIN itself, so the SUPI travels in the clear. no yes The ME reads the list and selects the highest priority scheme that it supports. Example 01 on this page is ECIES profile A reached this way. Three cases force the null-scheme whatever the USIM holds : an unauthenticated emergency session with no 5G-GUTI for the chosen PLMN, a home network that configured null-scheme, and a home network that never provisioned the public key. ( 33.501 clause 6.12.2 )

The left column is the decision the UE follows. The two branches on the right are the endings that never reach the ME priority list.

When the USIM keeps the calculation, the ME is given nothing. No Home Network Public Key Identifier, no Home Network Public Key, no Protection Scheme Identifier. The ME must also delete anything of that kind it had cached earlier. An operator taking this route is advised to use a proprietary scheme identifier, which is what the range 0xC to 0xF exists for.

When the ME keeps the calculation, the USIM instead holds an ordered priority list of protection scheme identifiers. The ME reads the SUPI, the SUPI Type, the Routing Indicator, the key identifier, the public key and that list. It then selects the scheme with the highest priority among those it supports, which is not always the first entry. The reason is forward compatibility. A newer release can define a scheme that an older ME does not implement, so the list is written for MEs built after the USIM was issued.

When the null scheme is allowed

Example 02 above shows a SUCI with Protection sheme id = 0 and the MSIN printed beside it. That looks like the exact hole 5G was meant to close, so it is worth stating precisely when a UE may do this. 33.501 gives three cases and no others.

  • The UE is making an unauthenticated emergency session and has no 5G-GUTI for the chosen PLMN.
  • The home network has configured the null-scheme to be used.
  • The home network never provisioned the public key needed to build a concealed SUCI.

A fourth case sits in clause 6.12.4 and it is narrower. If the UE registers for emergency services and then receives an Identity Request, it uses the null-scheme for that Identity Response. The cost is stated plainly in the same clause. Registration for emergency does not provide subscription identifier confidentiality.

The null-scheme itself takes one line to define. It returns the same output as the input, for encryption and for decryption alike. Freshness is therefore irrelevant, because there is nothing to unlink. Every ME is required to support it.

What the fields hold

The structure lists further up this page name the fields and their widths. 23.003 clause 2.2B gives the value ranges, and several of them are tighter than the field width suggests.

  • SUPI Type : 0 is IMSI, 1 is Network Specific Identifier, 2 is Global Line Identifier, 3 is Global Cable Identifier, and 4 to 7 are spare. The lists above show the first two. The quoted 24.501 table above already mentions GLI and GCI, so all four are in use.
  • Routing Indicator : 1 to 4 decimal digits. Every digit counts, so 012 and 12 are different values. If the USIM carries no Routing Indicator, the field is set to the single digit 0, which is what both examples above show.
  • Protection Scheme Identifier : 0 to 15. 0x0 is null, 0x1 is Profile A, 0x2 is Profile B, 0x3 to 0xB are reserved for future 3GPP schemes and 0xC to 0xF are proprietary. A GLI or a GCI must use the null scheme.
  • Home Network Public Key Identifier : 0 to 255, and 23.003 sets it to 0 if and only if the null scheme is used. Example 01 shows 2 with ECIES profile A, and Example 02 shows 0 with the null scheme, so both captures obey the rule.

The Scheme Output has fixed parts and one variable part, and the sizes are stated in Annex C. Profile A is a 256-bit public key, a 64-bit MAC, plus the size of the input. Profile B is the same with a 264-bit public key. Check that against Example 01. The ECC ephemeral public key runs to 64 hexadecimal digits, which is 256 bits, and the MAC tag runs to 16, which is 64 bits.

Now look at the third part. The ciphertext in Example 01 is 0x294a3f4f32, which is 10 hexadecimal digits. The MSIN enters the scheme as packed BCD, so 10 digits occupy 5 octets, and ECIES leaves the ciphertext the same length as its input. That capture therefore has a 10 digit MSIN, and anyone reading the message can tell, without decrypting anything. Concealment hides the value and not the length.

  • A SUCI is built rarely, not constantly : the trigger is having no 5G-GUTI for that PLMN. A UE holding a valid 5G-GUTI never builds one, which is why 5G-GUTI dominates a normal log.
  • The USIM decides who does the work : if it keeps the calculation, the ME receives no key, no key identifier and no scheme identifier. It must also delete any it cached before.
  • Highest priority means highest supported : the ME skips entries it does not implement, because the list is written to survive schemes defined after the ME was built.
  • Three cases permit the null scheme : unauthenticated emergency with no 5G-GUTI, a home network that configured it, and a home network that never provisioned a public key. Emergency registration is stated to give no identifier confidentiality.
  • The key identifier is 0 exactly when the scheme is null : 23.003 makes that an if and only if. A non-zero identifier beside scheme 0 is a decoding error, not an unusual configuration.
  • The ciphertext length leaks the MSIN length : ECIES adds a fixed 256 or 264 bit key and a fixed 64 bit tag, and the rest is the packed BCD input. Ten hexadecimal digits of ciphertext means ten MSIN digits.
  • A fresh ephemeral key pair is required per SUCI : the UE generates one for every calculation, which is what stops two SUCIs from the same subscriber being linked. The home network is explicitly not required to do the same.

Reference