srsUE integrity check bypass

[unrloay2]

Issue Description

[Describe the issue in detail]

1. srsUE does not check the integrity of the NAS message if the security header type is set to 0x4 (Integrity protected and ciphered with new EPS security context), and the MAC is set to any value. -- However, 0x4 should only be used for the Security Mode Complete, and also integrity protection should not be bypassed.

2. srsUE accepts plain EMM information, Detach Request, and Attach/Service Reject with emm_cause = # 25. -- However, UE should discard these messages if they are not integrity protected.

1 In the following function, https://github.com/srsran/srsRAN/blob/ce8a3cae171f08c9bce83ae3611e56f2d168d073/srsue/src/stack/upper/nas.cc#L468-L499 Any downlink message with sec_hdr_type=Integrity protected and ciphered with new EPS security context can pass the switch statement.

Then, it can also pass the message type checking function below, https://github.com/srsran/srsRAN/blob/ce8a3cae171f08c9bce83ae3611e56f2d168d073/srsue/src/stack/upper/nas.cc#L510-L530

Moreover, no parse function further checks the security header type, except for the parse_identity_request, which also improperly handles the security header type. https://github.com/srsran/srsRAN/blob/ce8a3cae171f08c9bce83ae3611e56f2d168d073/srsue/src/stack/upper/nas.cc#L541-L599

(srsUE sends identity response if sec_hdr_type>=1) https://github.com/srsran/srsRAN/blob/f2dff0b7a03e065060b48ea0a3c7a6a7890dfd46/srsue/src/stack/upper/nas.cc#L1141-L1142

In the end, srsUE processes the messages and performs corresponding behaviors (e.g. send IMEI/IMEISV before security activation).

2 Also, in the same message type checking function, srsUE accepts EMM information, Detach Request, and Attach/Service Reject with emm_cause = # 25 even if their security header type is set to plain.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably] e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

Expected Behavior

[What you expect to happen] UE should drop downlink messages with security header type 0x4. Also, UE should drop plain EMM information, Detach Request, and Attach/Service Reject with emm_cause = # 25.

Actual Behaviour

[What happens instead e.g. error message] UE doesn't drop them and performs corresponding behaviors

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files] When srsUE sends Attach Request, srsEPC sends i) NAS message with security header type 0x4 or ii) EMM Information, Detach Request, or Attach/Service Reject with emm_cause = # 25

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

[andrepuschmann]

Hey @unrloay2, I confirm the issues you explained. Are there any plans from your group to work on those and/or upstream patches?

[unrloay2]

@andrepuschmann Yes, we will push the patch soon :)

[andrepuschmann]

Thanks again @unrloay2 for your contributions. They have already been merged into master.