Security Mode Setup is the 5GMM procedure where the AMF selects NAS ciphering and integrity algorithms and asks the UE to activate the selected NAS security context. This procedure normally follows successful authentication. Once completed, later NAS messages are integrity protected and usually ciphered.

In a registration log, this is the point where the NAS messages change their look. Before it, most messages are plain. After it, every 5GMM message comes with an Auth code and a sequence number. So if you want to understand why a NAS message is or is not protected, this procedure is the place to start.

• Why we need Security Mode Setup ?
• Signaling Sequence
• Reading the Security Header
• Message Structure
  • Security Mode Command Contents
  • Security Mode Complete and Reject Contents
  • Example : Security Mode Command
  • Example : Security Mode Complete
• Reference

Why we need Security Mode Setup ?

Authentication already proved that the UE and the network share the same keys. Then you may ask why another procedure is needed before NAS security starts. The reason is that authentication only creates the key material. It does not say which algorithms to use, and it does not say from which message the UE and the AMF start using the keys. Both sides have to switch at exactly the same message. Otherwise one side would send protected messages that the other side reads as garbage.

The security mode control procedure solves this. The AMF picks one ciphering algorithm and one integrity algorithm, and names the key set with the ngKSI. The SECURITY MODE COMMAND is the first message protected with the new context, and the SECURITY MODE COMPLETE is the first message that is both integrity protected and ciphered with it.

There is one more job hidden in this procedure. The AMF sends back the UE security capabilities it received from the UE, as the Replayed UE security capabilities IE. The UE compares them with what it sent. If an attacker had changed the capabilities on the way, for example to force a weaker algorithm, the UE detects it here and rejects the command.

• Authentication makes the keys, security mode control starts using them : the two procedures are separate, and the second one usually follows the first directly.
• The algorithms are chosen by the AMF : the UE offers its capabilities in the registration request, and the AMF selects from them.
• The replayed capabilities protect against bidding down : a mismatch makes the UE reject the command with 5GMM cause #23.
• The procedure is also used later : the AMF can run it again to change the algorithms of a context already in use, or to give the UE the EPS NAS algorithms.

Signaling Sequence

The procedure itself is only two messages, and the AMF guards it with T3560. The following table shows the two possible answers of the UE. The command is always followed by exactly one of them, a Complete or a Reject.

In a real log, this procedure almost never appears alone. It sits in the middle of an initial registration, between authentication and the registration accept. The following table shows that context, which is also the context of the examples below.

Then what if the UE does not answer ? T3560 is 6 seconds in normal NR access. On each of the first four expiries the AMF retransmits the SECURITY MODE COMMAND, and on the fifth expiry it aborts the procedure. If the UE answers with a SECURITY MODE REJECT, the AMF stops T3560 and also aborts the procedure that triggered the security mode control, which is usually the registration.

The reject carries one of two causes. #23 UE security capabilities mismatch means the replayed capabilities did not match what the UE sent. #24 security mode rejected, unspecified covers the other reasons. The reject itself is protected with the old security context, if there is one, because the new context was never accepted.

• T3560 is 6s, with four retransmissions : the same timer also guards the authentication request.
• A reject aborts the parent procedure : the registration that triggered the security mode control ends there as well.
• #23 points at the replayed capabilities : compare the capabilities in the command with the ones in the registration request.

Reading the Security Header

How can you tell from a log that the security mode control worked ? The quickest way is the security header type at the top of each 5GMM message. This procedure is the only place where the two new context values appear. So the header alone tells you where a message sits relative to the switch.

Why is the command not ciphered ? The UE cannot decipher anything until it knows which algorithm and which key set to use, and that information is inside the command itself. So the AMF can only integrity protect it. The UE reads the algorithms in clear, takes the context into use, and checks the integrity. From the Complete onward, both directions are ciphered.

One more thing to remember. Ciphered does not always mean encrypted. If the AMF selects 5G-EA0, the null ciphering algorithm, the header still says ciphered but the payload goes in clear. The example below is exactly this case.

• 0x3 and 0x4 appear only in this procedure : they mark the first downlink and the first uplink message of a new context.
• The command is never ciphered : the UE needs the selected algorithms from it before it can decipher anything.
• Sequence numbers restart with a new context : a fresh context after authentication starts the NAS COUNT from 0.

Message Structure

Security Mode Command contains the selected NAS security algorithms, ngKSI, replayed UE security capabilities and optional requests such as IMEISV request. Security Mode Complete may include IMEISV and a NAS message container, for example a replayed Registration Request protected with the new security context.

Security Mode Command Contents

Following is 24.501 Table 8.2.25.1.1, without the header IEs. The first three rows are mandatory, and they are the whole point of the message. The optional rows ask the UE for something extra, or give it extra key derivation input.

Pay attention to the RINMR bit. The AMF sets it when the initial REGISTRATION REQUEST failed the integrity check, or when the AMF could not decipher its NAS message container. In the first case the AMF cannot trust what it received, and in the second it cannot read it. So it asks the UE to send the whole registration request again under the new context.

Security Mode Complete and Reject Contents

Following are 24.501 Tables 8.2.26.1.1 and 8.2.27.1.1, again without the header IEs. The Complete has only optional IEs, and each of them answers something the command asked for. The Reject has a single mandatory 5GMM cause.

When the Complete carries a REGISTRATION REQUEST in the NAS message container, the AMF uses that inner message as the message that triggered the registration. The registration request sent before the security mode control is replaced by this protected copy.

Example : Security Mode Command

The following example is based on an Amarisoft MME log captured after successful primary authentication. The whole decoded NAS message is shown below. It is the first NAS message protected with the new context, so start with the header.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:34.041 [NAS] DL 0064 5GMM: Security mode command
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x3 (Integrity protected with new 5G NAS security context)
        Auth code = 0xa34d93a1
        Sequence number = 0x00
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x5d (Security mode command)
        Selected NAS security algorithms = 0x02 (5G-EA0, 5G-IA2)
        ngKSI:
          TSC = 0
          NAS key set identifier = 3
        Replayed UE security capabilities:
          0xf0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=1, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)
          0x70 (5G-IA0=0, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=1, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)
          0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)
          0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)
        IMEISV request = 1
        Additional 5G security information = 0x02 (RINMR=1, HDP=0)

There are a couple of points that I want you to notice here. First, the security header is 0x3, integrity protected with new 5G NAS security context, and the sequence number is 0. This is the first message of the new context, and it is not ciphered.

Second, look at the selected algorithms, 0x02. The upper nibble is 0, which is 5G-EA0, and the lower nibble is 2, which is 128-5G-IA2. So this network turns on integrity protection but selects null ciphering. That is common in a test setup, because the log stays readable. In a commercial network you would usually see a non-zero ciphering algorithm here.

Third, the command asks for two things. IMEISV request = 1 asks for the IMEISV, and RINMR = 1 asks for the initial registration request again. HDP = 0 means no horizontal KAMF derivation.

• ngKSI 3 with TSC 0 : the AMF takes a native context with key set identifier 3 into use.
• The replayed capabilities are 0xf0 0x70 0xf0 0x70 : these four octets must match the UE security capability the UE sent.
• 5G-IA0 is not supported by this UE : the replayed capabilities show 5G-IA0=0, so null integrity could not be selected here anyway.

Example : Security Mode Complete

The following example is based on the matching Security Mode Complete from the same Amarisoft MME log. The whole decoded NAS message is shown below.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:34.081 [NAS] UL 0064 5GMM: Security mode complete
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x4 (Integrity protected and ciphered with new 5G NAS security context)
        Auth code = 0x3308aa89
        Sequence number = 0x00
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x5e (Security mode complete)
        IMEISV:
          IMEISV = 8690570563562913
        NAS message container:
          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 = 2
          5GS mobile identity:
            5G-GUTI
              MCC = 001
              MNC = 01 
              AMF Region ID = 128
              AMF Set ID = 4
              AMF Pointer = 1
              5G-TMSI = 0x9c66ee06
          5GMM capability:
            0x03 (SGC=0, 5G-IPHC-CP CIoT=0, N3 data=0, 5G-CP CIoT=0, RestrictEC=0, LPP=0, HO attach=1, S1 mode=1)
          UE security capability:
            0xf0 (5G-EA0=1, 128-5G-EA1=1, 128-5G-EA2=1, 128-5G-EA3=1, 5G-EA4=0, 5G-EA5=0, 5G-EA6=0, 5G-EA7=0)
            0x70 (5G-IA0=0, 128-5G-IA1=1, 128-5G-IA2=1, 128-5G-IA3=1, 5G-IA4=0, 5G-IA5=0, 5G-IA6=0, 5G-IA7=0)
            0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)
            0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)
          Requested NSSAI:
            S-NSSAI
              Length of S-NSSAI contents = 1 (SST)
              SST = 0x01
          Last visited registered TAI:
            MCC = 001
            MNC = 01 
            TAC = 0x000064
          S1 UE network capability:
            0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)
            0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)
            0xc0 (UEA0=1, UEA1=1, UEA2=0, UEA3=0, UEA4=0, UEA5=0, UEA6=0, UEA7=0)
            0x40 (UCS2=0, UIA1=1, UIA2=0, UIA3=0, UIA4=0, UIA5=0, UIA6=0, UIA7=0)
            0x19 (ProSe-dd=0, ProSe=0, H.245-ASH=0, ACC-CSFB=1, LPP=1, LCS=0, 1xSRVCC=0, NF=1)
            0x80 (ePCO=1, HC-CP CIoT=0, ERw/oPDN=0, S1-U data=0, UP CIoT=0, CP CIoT=0, ProSe-relay=0, ProSe-dc=0)
            0xb0 (15 bearers=1, SGC=0, N1mode=1, DCNR=1, CP backoff=0, RestrictEC=0, V2X PC5=0, multipleDRB=0)
          UE's usage setting = 0x01 (Data centric)
          LADN indication:
            Length = 0
            Data =
          Network slicing indication = 0x00 (DCNI=0, NSSCI=0)
          5GS update type = 0x01 (EPS-PNB-CIoT=no additional information, 5GS-PNB-CIoT=no additional information, NG-RAN-RCU=0, SMS requested=1)

The Complete arrives 40 ms after the command. Its security header is 0x4, and its sequence number is again 0, because this is the first uplink message of the new context. Each answer to the command is here. The IMEISV answers the IMEISV request, and the NAS message container answers RINMR = 1.

Now look at the UE security capability inside the container. It is 0xf0 0x70 0xf0 0x70, exactly the same as the replayed capabilities in the command. This is the check that the UE made before it accepted the command, and you can repeat it by eye in the log.

One more detail is a little confusing at first. The registration request in the container says ngKSI 2, while the command uses ngKSI 3. My understanding is that the container repeats the initial registration request as the UE first sent it. At that time the UE pointed at its old context, key set 2. Most likely the AMF could not verify that message with context 2, so it ran authentication, created key set 3, and set RINMR to get the request again under the new context.

• The container carries the full registration request : the AMF now treats this copy as the message that triggered the registration.
• The ngKSI in the container is the old one : it shows what the UE asked for before authentication, not the context now in use.
• Ciphered with 5G-EA0 means readable : the header says ciphered, but the selected algorithm is null ciphering.

Reference

The procedure, the timer, the security header values and the message contents on this page were checked against 24.501.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). The security mode control procedure in clause 5.4.2, the message contents in Tables 8.2.25.1.1, 8.2.26.1.1 and 8.2.27.1.1, the Additional 5G security information IE in clause 9.11.3.12 and the T3560 timer table. The version read was v20.1.0 (Release 20).
• 33.501 : Security architecture and procedures for 5G system. Named by 24.501 for the key derivation and the initial NAS message protection. Not read directly for this page.
• Authentication and Registration : the procedures before and around the security mode control.