5G priorities enable Machine-to-Machine and Ultra-Reliable Low-Latency Communication objectives to be taken the next step by building in mechanisms for the IoT devices into the protocols. This opens the door for many more IoT devices and services to be brought online. This heterogeneous mix of devices will consist of new 5G New Radio supported devices and legacy 4G LTE devices that use cellular as their common communication channel connecting to each other and to a wide variety of IoT applications.
Looking at the common communication channel to the edge device, 3GPP has instrumented features and security mechanisms to address existing 4G security concerns as well as enabling Low-Power Wide-Area (LPWA) capabilities.
That being said, making the promise of IoT a reality is a team effort. Special interest groups such as GSMA, NIST and ENISA are developing industry recommendations as a way of securing the end to end IoT domain. Some of those recommendations are being implemented today. In the end, the communication channel from the end device to the application server and back may be more secure that in previous generations of cyber-physical systems but it is not foolproof. If fully implemented, the recommendations appear to improve some security areas while exposing others that are harder to close with technology alone.
The Internet of Things
The promise of the Internet of Things (IoT) is for heterogeneous devices, or machines, to communicate with other devices/machines for a common purpose without human intervention, also known as Machine-to-Machine (M2M) communication or Machine-Type Communication (MTC). In order to achieve this, MTC devices need a common communication channel: either be a dedicated IoT network for short range data transactions or the established cellular network.
Illustration 1: Current and envisioned cellular-based network architectures for supporting MTC services 
Illustration 2 provides a high-level overview of the different IoT technologies. Note that the range of IoT MTC devices span from Personal Area Network to Wide Area Network. To achieve long range connectivity, getting to the most remote of locations, existing cellular network infrastructure provides a convenient option for a common communication channel.
Illustration 2: Technologies associated with 5G-IoT
NB-IoT and LTE Cat M1 are two Cellular IoT (CIoT) technologies that are supported by 3GPP cellular standards, leveraging the existing LTE infrastructure to provide connectivity for MTC devices. 3GPP continues to refine support for MTC devices by adding additional capabilities for the technologies on the existing LTE Radio Access Technology (RAT). As NB-IoT and LTE Cat M1 technologies were developed to address IoT device needs (variable data payloads, variable network transaction frequencies) these technologies already meet the requirements for massive MTC (mMTC) and Ultra-Reliable Low-Latency Communications (URLCC) goals of 5G and have been adopted into the umbrella of 5G technologies, yet there is currently no IoT-specific signaling that rides over the 5G Core Network; it all goes through the LTE Enhanced Packet Core (EPC). Therefore 5G, as an umbrella technology, contains support for NB-IoT and LTE Cat M1, it still utilizes the LTE core network for the work because both of these IoT protocols are meeting the needs. As 5G matures, it is expected to see additional mechanisms added to the 5G protocol to enable mMTC, critical MTC (cMTC) and URLLC.
5G also prescribes Network Virtualized Functions (NVF) where the network can provide on-demand services which will bring about their own level of cybersecurity challenges to protect the interconnect between NVF.
Cellular IoT Security is a Team Sport
There is a security recommendation for every layer in the graph. GSMA provides NB-IoT and general IoT security guidance for the endpoint, IoT service providers, and the Mobile Network Operator (MNO). The European Union Agency for Cybersecurity (ENISA) also provides security recommendations and gap analysis for IoT deployments. NIST provides recommendations on IoT endpoint device security.
It is evident from all the security recommendations from telecommunications consortiums a safe and secure IoT deployment is in the best interest of industry. As the IoT evolution continues, 3GPP is providing hooks for features to enable the interconnected, machine-learning Industry 4.0.
Cellular IoT Communication Channel
As mentioned before, NB-IoT uses 4G/LTE infrastructure.
NB-IoT devices utilize a similar Connection and Attach procedure as LTE, using NB-IoT messages and frequency bandwidth either in-band or in-guard band with existing LTE bands. This means that NB-IoT can ride alongside LTE technology and may share the same vulnerabilities as LTE.
When looking at the NB-IoT random access procedures and comparing to the LTE random access procedures, the messages are logically similar but are on different channels. The C-ANTI is exchanged in this process. According to , the C-RNTI can be used to follow subsequent messages from the network (AMF in , but the same messages are in LTE). From this, it can be concluded that an NB-IoT devices has the samprotocol vulnerabilities as LTE. 5G signaling prevents the clear-text transmission of the ue-identifier (the SUPI) meaning that it will be harder to derive the unique mobile identifier than requesting the IMSI in LTE (through the NAS Identification request).
Release 16 of the 3GPP TS 36.331, focusing on the RRC, specifies some unique messaging that applies to NB-IoT devices.
RRC Connection Suspend/Resume allows the network or the UE to “suspend” the RRC connection, freeing up resources on the link. When the network or the UE wish to “resume”, the cached security contexts are recalled and used. This saves time and radio resources to re-establish the NAS and AS security parameters.
Caching the context could provide a way to break the MME, by forcing massive amounts of RRC Connections to be suspended, keeping some amount of resources locked in, amounting to a memory leak. If an attacker was able to disrupt the communication from the MME to the eNB and other RAN assets, then there may be timing mis-matches for the distribution of the ciphering and integrity checking among the RAN elements (such as the eNB). For 5G where the SUCI is exchanged during an identity request, a similar methodology may be used.
With the encryption and integrity protection being better in 4G than in 3G (due to the Subscriber Identification Module (SIM) capabilities), these keys may be harder to crack. This means that having access to them in either the MTC device or the MME could be very damaging. It would be worthwhile to review the physical protection mechanisms around access and authroization to the MME (4G) and AMF (5G) to ensure keys are well protected in the core network. More over, industry is encouraged to continue to up the security around their cryptographic storage in MTC devices.
The MTC devices uses “radio bearers” to communicate with the eNB and the Core Network (CN). A radio bearer is a logical entity used to transport information between the UE and the CN. Data Radio Bearers (DRBs) carry user plane data. Signaling Radio Bearers (SRBs) carry control plane information. SRB0 and SRB1 are established between the UE and the RRC, SRB2 runs between the UE and the RRC and the UE and the MME. Data Radio Bearers (DRBs) are established between the UE and the RRC after the NAS signaling is complete and the UE has been authenticated on the network. After the NAS attach is complete, the mobile has access to the radio link and to the packet core. CIoT devices are limited to 3 DRBs, max.
SRBs carry control plane data which is both ciphered and integrity protected. DRBs carry user plane data and are only ciphered.
Depending on configurations, data can be encapsulated in IP or non-IP headers.
IP Data Delivery over DRBs
For comparison, a brief description of how data flows for an H2H device (say a mobile phone), is provided.
After attaching to the network, the mobile device will at some point send a NAS service request to the network requesting air time to transfer data. Resources are allocated in the core network and the connection between the eNB and the Serving Gateway (S-GW) for the mobile is established. After resources are granted, the mobile will use the its established DRB to transfer the IP-encapsulated data, following the green line in Illustration 3, from the eNB to the S-GW to the Packet Gateway (P-GW) and then out to the Internet.
Use of the DRBs is best for connection oriented services which is great for most mobile applications that have an “always on” feel to them. However, IoT services have different goals like conserving battery life as much as possible. Data over Non-Access Stratum (DoNAS) is one optimization that is targeted towards IoT data needs.
Illustration 3: IP Data delivery from IoT device to Application Server
Data over Non-Access Stratum (DoNAS)
DoNAS piggybacks user plane data into the control plane messages thereby reducing latency to transmit data by not requiring Data Radio Bearers to be established. DoNAS is also referred to as Control Plane CIoT EPS Optimization which is mandatory for IoT/MTC devices to implement.
As shown by the purple line in Illustration 3, the IoT device sends Data over NAS via the a NAS container within the RRC Connection Setup Complete message over NAS signaling to the MME. At this point in the message flow, the control plane encryption and integrity protection keys have been established. Meaning that the data transmitted over the NAS control plane is ciphered and integrity protected. The MME routes the IP data to the S-GW, then to the P-GW and out to the internet.
Data delivered DoNAS can be IP or Non-IP encapsulated to gain further efficiencies in the transport of data.
- Non-IP Data Delivery (NIDD)
Non-IP Data Delivery works in conjunction with DoNAS allowing devices to utilize the control plane for small amounts of non-IP data. Illustration 4 is a representation of the data flow between an CIoT device and the IoT Application provider. The Service Capability Exposure Function (SCEF) provides core network functions to non-core networks, such as an IoT Service provided.
Prior to data transfer, the Customer’s Network registers with the SCEF. So does the UE, thereby establishing a logical path from IoT device to IoT Service provider. Just like in DoNAS, the control plane data is routed to the MME and then is routed to the SCEF to be transported to the Customer’s Network.
There are a few major transfer protocols in use by IoT Service providers: MQTT and CoAP. Both protocols have security flaws that could result in DDoS, flooding end devices and the CIoT.  Endpoint devices such as the u-blox SARA-R5 implements the 3GPP extended Access Barring as a way of helping the CN identify and block devices that are causing issues on the network.
Illustration 4: Non-IP Data Delivery
Suspend and Resume
3GPP specifications provide for the ability of per-associated IoT devices to re-use the established security context through use of RRC suspend and resume messages. This is also known as User Plane CIoT EPS Optimization and is an optional mechanism for an IoT devices to support. When the radio link is suspended, both the IoT device and the CN cache the security context. The security context is restored when the IoT device resumes. 
This scenario is best suited for exchanges of sequence of messages.
With all the context being stored in a massive MTC use case, it would be interesting to look at how the context are stored and quickly retrieved to keep the latency low. Techniques to disrupt or deny the suspend/resume mechanism are provided for in .
Evaluation Against Security Recommendations
Mobile Network Operators
GSMA provides security guidelines for Network Operators supporting IoT devices. There are four recommended principles to consider with regards to the current NB-IoT specifications and the future evolution of IoT devices in 5G (mMTC and URLLC).
|Principle||How does NB-IoT achieve?||How might 5G achieve?|
|Secure Identification of Users, Applications, Endpoint Devices, Networks and Service Platforms||Using identity mapping techniques of , it is possible to obtain the IMSI for the device and then to spoof the device (or the base station).||Using the identity mapping technique of , it is possible to obtain the SUCI. The SUCI is an obfuscated version of the SUPI.|
|Secure Authentication of Users, Applications, Endpoint Devices, Networks and Service Platforms||The NAS Identity request will ask the UE to provide its IMSI.||The NAS Identity request will provide the SUCI.|
|Provide Secure Communication Channels||Looking at an LTE network that carries NB-IoT technology, the EPC can establish a VPN with the APN for the IoT device. The security of this will be whatever is negotiated between the EPC and the IoT/MTC services. (NIDD)||Looking at a 5G network, when CIoT devices being to leverage the 5G CN, the recommendation will be to secure the communication channels between the Network Virtualization Function (NVF) nodes.|
|Ensure Availability of Communication Channels||For Power Savings Mode or eDRX enabled NB-IoT devices, it is recommended that the MNO take a “store and forward” approach, delivering only when the mobile wakes back up (either through timeout expiry or paging).||NB-IoT operates among LTE and 5G spectrum. It is designed to be a non-factor to the Human-to-Human traffic carried on those Radio Access Technologies thus NB-IoT deployments using the same cells does not take away resource blocks from the H2H UEs.|
Table 1: GSMA Recommendations for IoT MNOs
Release 10 offered some initial thoughts on how to bar devices which has been iterated on over the years. There is an extended Access Barring functionality that goes by classes. This is all an attempt by the cellular network to identify and isolate end points that are creating excessive traffice in the network. This allows the radio link to remain available for more “well behaved” devices.
ublox appears to be an industry leader providing LTE Cat M1 and NB-IoT radios and modules, with security in mind from the start and supporting 5G New Radio waveformes today. A brief and focused review of the SARA-R5 module is presented in Table 2 with respect to the GSMA NB-IoT Deployment Guide.
The SARA-R5 has tamper protection monitoring the security element (implementation of the Root of Trust) securing the integrity of the NB-IoT module. The R5 also has hardware based Root of Trust built in, enabling sense of security in cryptographic material generated for applications as well as protecting highly secure pieces of code.
The R5 also uses a USIM instead of the SIM used on the R4. This allows for stronger keys to be generated for authentication on the LTE network. If the NB-IoT key material is stored within the Root of Trust security element, then it appears that the R5 supports confident authentication of both the communication channel (the LTE network) and the MTC application layer, taking a step forward in protecting the end-to-end data transfer from the MTC device to the MTC server.
The R4 and R5 modules both support CIoT features targeted to low complexity, small data frames and long battery life by implementing Power Savings Mode (PSM)
extended Discontinuous Reception (eDRX). These features are carried forward into Release 16 as part of 5G. The R5 module does implement new RRC messaging to allow a previous attach session to reconnect using the prior keys for encryption and integrity checking.
|Feature||SARA-R5||Meets GSMA Recommendation||Cyber-Physical System Principle|
|Tamper Detection||Hardware-based Root of Trust provides tamper detection for cryptographic material running in a secure element on the hardware.||Integrity Non-Repudiation if Root of Trust supported encryption used for application layer.|
|Identification Module||Universal Subscriber Idenrification Module (USIM)||N/A||Authentication Confidentiality|
|3GPP Release||Release 14|
Supports RRCConnectionResume/Suspend messaging RAN overload control for MTC – extended access barring R11
|R5 meets recommendation for AS-level congestion control||Meets LPWA requirements for efficient data transfers|
|Data Delivery||IP, Non-IP, Control Plane CIoT EPS Optimization||R5 meet recommendation for IP over Control Plane||Meets LPWA goal for efficient data delivery|
Table 2: ublox NB-IoT comparison
It is not clear where the username and password is stored for the cellular carrier’s Access Point Name (APN). Limited information was available online for free on this topic through u-blox website. It appears that the username and password can be configured through AT commands. It is assumed to be stored on the Universal Subscriber Identity Module (USIM) for the R5.
The R5 firmware can be updated over the air (FOTA or uFOTA). This allows the firmware in the module to be updated and patched as security vulnerabilities surface in the future.
The SARA-R5 module is the cellular component. It does nothing for Veracity or Plausbility of the data from attached sensors.
Cyber-Physical System Walk Through
Turning back to Illustration 1, repeated here for convenience, there are cyber-physical system security concerns at each level.
Illustration 5: Current and envisioned cellular-based network architectures for supporting MTC services 
Here is a walkthrough for an MTC device sending data to its MTC application (IoT Service). Assume that, for the purposes of this walk-through, there is a temperature sensor connected to an MTC device in the picture. And let’s just assume that the CPS concerns regarding veracity and plausibiity for the temperature sensor are known. And let’s also say that the MTC device that is connected to the temperature sensors is a SARA-R5 NB-IoT module which has just been powered on.
- SARA needs to register with the network.
- Transmission of the C-RNTI allows the messages to be followed, potentially leaking personal information and/or exposing the device to DoS and spoofing attacks.
- SARA completes the NAS Attach and then issues a RRC Connection Suspend message, caching the security context for the connection.
- If a rogue eNB has enough information to spoof SARA, it could issue false resume requests thereby resetting the cached context. When SARA wakes up, it will have to restart the attach process, potentially leading to DoS attack through inability to actually attach to the network.
- SARA initiates the RRC Connection Resume request and hopefully the saved context still works. Reads the temperature data from the sensor and transfers that using DoNAS and Non-IP Data Delivery.
- The network tunnels the data to the IoT Service.
This walk through shows that at each step in the process, there is opportunity for security concerns to come into play.
At least one NB-IoT device is tracking to 3GPP standards and GSMA Recommendations of delivering NB-IoT services. With each new feature provided by 3GPP, there seem to be opportunities for misconfiguration or weakening of the services provided, however, through the compilation of security recommendations at various levels, implementers have many references to provide contemplative thought.
Industry is improving the security of the communication channel devices leaving opportunity to consider the veracity of the data going into said MTC device. Physical security is going to become increasingly important as devices push opportunistic attack points farther to the edges of the network. One would need to be physically present to try and tamper with the SARA-R5 module, for example, but there is tamper logic built into as well as a secure element that evaluate the code it is going to execute. This leaves the application data to be the weak point, oftentimes requiring physical presence to modify the sensor or actuator or the ability to get into the network resources behind the mTCdevice.
LTE has been broken at Layer 2 and the same techniques appear to work for 5G as well. This means that there will be some amount of attacks on the communication channel between the core network and the endpoint device. For critical IoT applications, any attack leading to re-starting the attach procedure will not do. The SUPI never being transmitted in plain-text will provide some level of obfuscation but does not prevent Denial of Service attacks.
With each new iteration of features and capabilities, the community at large looks to shore up security for IoT devices and services pushing more physical security concerns to the forefront as technology and security recommendations provide cover.
 Liberg, Olof, Mårten Sundberg, Y.-P. Eric Wang, Johan Bergman, and Joachim Sachs. Cellular Internet of Things : Technologies, Standards, and Performance. London, United Kingdom: Academic Press, 2018. https://ezproxy.depaul.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=nlebk&AN=1523441&site=ehost-live&scope=site.
 Shariatmadari, Hamidreza, Rapeepat Ratasuk, Sassan Iraji, Andrés Laya, Tarik Taleb, Riku Jäntti, and Amitava Ghosh. “Machine-Type Communications: Current Status and Future Perspectives toward 5G Systems.” IEEE Communications Magazine 53, no. 9 (September 2015): 10–17. https://doi.org/10.1109/MCOM.2015.7263367.
 Hussain, Syed Rafiul, Mitziu Echeverria, Imtiaz Karim, Omar Chowdhury, and Elisa Bertino. “5GReasoner: A Property-Directed Security and Privacy Analysis Framework for 5G Cellular Network Protocol.” In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 669–84. London United Kingdom: ACM, 2019. https://doi.org/10.1145/3319535.3354263.
 Akpakwu, Godfrey Anuga, Bruno J. Silva, Gerhard P. Hancke, and Adnan M. Abu-Mahfouz. “A Survey on 5G Networks for the Internet of Things: Communication Technologies and Challenges.” IEEE Access 6 (2018): 3619–47. https://doi.org/10.1109/ACCESS.2017.2779844.
 Li, Shancang, Li Da Xu, and Shanshan Zhao. “5G Internet of Things: A Survey,” n.d., 28.
 Rupprecht, David, Katharina Kohls, Thorsten Holz, and Christina Pöpper. “Breaking LTE on Layer Two.” In 2019 IEEE Symposium on Security and Privacy (SP), 1121–36, 2019. https://doi.org/10.1109/SP.2019.00006.
 Liberg, Olof, Marten Sundbert, Y.-P. Eric Wang, Johan Bergman, Joachim Sachs, and Gustav Wikstrom. Cellular Internet of Things, From Massive Deployments To Critical 5G Applications. Academic Press, 2020.
 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification (Release 16); TS 36.331.” 3GPP, March 2020.
 “Security-Features-of-LTE-M-and-NB-IoT-Networks.Pdf.” GSMA. Accessed June 9, 2020. https://www.gsma.com/iot/wp-content/uploads/2019/09/Security-Features-of-LTE-M-and-NB-IoT-Networks.pdf.
 “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) Protocol for 5G System (5GS); Stage 3; (Release 16); TS 24.501.” 3GPP, n.d.
 iot-mobile. “NON IP Data Delivery (NIDD).” Accessed June 2, 2020. https://docs.iot.t-mobile.nl/docs/non-ip-data-delivery-nidd.
 “IoT Security Guildelines for IoT Service Ecosystems.” GSMA. Accessed June 10, 2020. https://www.gsma.com/iot/wp-content/uploads/2020/05/CLP.12-v2.2-GSMA-IoT-Security-Guidelines-for-Service-Ecosystems.pdf.
 “NB-IoT Deployment Guide to Basic Feature Set Requirements.” GSMA, August 2, 2017. https://www.gsma.com/iot/wp-content/uploads/2017/08/CLP.28-v1.0.pdf.
 “IoT Security Guidelines for Network Operators, Version 2.2.” GSMA, February 29, 2020. https://www.gsma.com/iot/wp-content/uploads/2020/05/CLP.14-v2.2-GSMA-IoT-Security-Guidelines-for-Network-Operators.pdf.
 “SARA-R4 Series – Application-Development AppNote,” January 27, 2020. https://www.u-blox.com/en/docs/UBX-18019856.
 “SARA-R4 Series – System Integration Manual,” December 23, 2019. https://www.u-blox.com/en/docs/UBX-16029218.
 “SARA-R5 Series Presentation Investors,” June 11, 2019. https://www.u-blox.com/sites/default/files/documents/SARA-R5_Series_Presentation_Investors_final.pdf.
 “Product Summary UBX-R5 Multi-Band LTE-M / NB-IoT Chipset,” May 19, 2020. https://www.u-blox.com/sites/default/files/UBX-R5_ProductSummary_%28UBX-19026227%29.pdf.
 Just Ask Thales US. “What Is a UICC and How Is It Different from a SIM Card?,” August 17, 2015. https://justaskthales.com/us/what-uicc-and-how-it-different-sim-card/.
 Network Manias. “NB-IoT Deployment – What It Takes.” Accessed June 10, 2020. https://www.netmanias.com/en/?m=view&id=blog&no=11743.
 Andres-Maldonado, Pilar, Pablo Ameigeiras, Jonathan Prados-Garzon, Jorge Navarro-Ortiz, and Juan M. Lopez-Soler. “NarrowBand IoT Data Transmission Procedures for Massive Machine Type Communications.” IEEE Network 31, no. 6 (November 2017): 8–15. https://doi.org/10.1109/MNET.2017.1700081.
 Fagan, Michael, Katerina Megas, Karen Scarfone, and Matthew Smith. “Recommendations for IoT Device Manufacturers: Foundational Activities and Core Device Cybersecurity Capability Baseline (2nd Draft).” National Institute of Standards and Technology, January 7, 2020. https://doi.org/10.6028/NIST.IR.8259-draft2.
 “TS 22.104 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Requirements for Cyber-Physical Control Applications in Vertical Domains; Stage 1 (Release 17).” 3GPP, December 2019.
 “IoT Security Standards Gap Analysis.” Report/Study. Accessed June 11, 2020. https://www.enisa.europa.eu/publications/iot-security-standards-gap-analysis.
 Definition Networks. “3GPP SCEF Primer.” Accessed June 11, 2020. http://www.definitionnetworks.com/3gpp-scef-primer/.
 “What Is Industry 4.0—the Industrial Internet of Things (IIoT)?” Accessed June 11, 2020. https://www.epicor.com/en-us/resource-center/articles/what-is-industry-4-0/.
 “MQTT and CoAP: Security and Privacy Issues in IoT and IIoT Communication Protocols – Security News – Trend Micro USA.” Accessed June 11, 2020. https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/mqtt-and-coap-security-and-privacy-issues-in-iot-and-iiot-communication-protocols.
 Help Net Security. “IoT Devices Using CoAP Increasingly Used in DDoS Attacks,” March 8, 2019. https://www.helpnetsecurity.com/2019/03/08/iot-coap-ddos-weapon/.