The way mobile networks are designed, phones are bound to initially send some information towards the network on NAS* layer in an unencrypted fashion. This is required, since there exists no shared security context between the User Equipment (UE) and the network at the time of the first attach, i.e. no cryptographic keys to keep these very first messages confidential. Plus, even when such a shared context exisits, it needs to be identified by some information in the clear. If it only was that limited set of information elements that would be transferred unprotected, there would not be an issue. However, for conveniece and/or efficiency, it might be desireable to include additional information into these messages. A prime example in 5G being the slice identifier, used to identify specific traffic classes that are processsed differently than others to cater for special requirements. With this information being present right from the beginning, it is possible to route such traffic to dedicated network function instances directly, without first taking a default route and having to wait for subsequent signalling from the UE to determine the correct slice.
Quite obviously, a privacy issue arises as more data gets added to initial NAS messages, since all this information is revealed over the air. Taking the slice identifier as an example, eavesdroppers would be able to detect special slices (e.g. critial communication slices for police, emergency services, etc.) used by UEs in the vicinity. Depending on the situation and exact slices, this information can be considered sensitive and revealing it at every attach would be a grave oversight.
What is done in 5G to protect these initial NAS messages is actually quite simple: If a UE already has a stored security context, e.g. from an earlier connection to the same network, additional information elements that are not necessary to establish a secure NAS connection will be encrypted before transfer. Thus, no such information is revealed on the air interface. At the receiving end, the Access and Mobility Management Function (AMF) tries to find a matching security context locally or by contacting other instances, in case the UE was connected to a different AMF earlier. If it fails to recover the context, a fresh authentication and key agreement is initiated by the network.
Conversely, if the UE attempts to connect and does not have a security context, yet, all additional information is omitted from the initial message and will be sent in protected NAS messages later on. In that case the only information elements that are contained in the initial message are the UE's subscription identifier (i.e. SUCI or GUTI), its security capabilities, the key set identifier ngKSI, an additional GUTI, an indication that the UE is moving from EPC to 5GC, and the EPS Tracking Area Update (TAU) Request in case of idle mode mobility from 4G to 5G.
Until now, we have only touched on confidentiality of information transferred over the air. So what about integrity? Already in 4G, integrity is ensured by the network sending a hash over the initial message to the UE once a secure NAS connection was successfully set up. The UE computes the same hash, compares both values and takes action accordingly. If the message sent to the network was altered in some way, i.e. hash comparison fails, the contained information is transferred again within a protected NAS message.
As for 5G, if the UE does not have a security context to protect the initial message, the message itself is transferred again completely in the protected NAS Security Mode Complete message. If it does have a security context and includes additional information into the initial message, the complete message may be included on request by the AMF. That way it is ensured the network ends up with the correct, unaltered information from the initial messages.