Cellular IoT Module Design and Manufacturing—Ensuring Security at Birth

Security of Internet of Things (IoT) solutions is increasing in importance and gaining greater attention, particularly because IoT hardware and devices come from supply chains that touch multiple countries from around the world. Longer supply chains consisting of suppliers of hardware and associated software give more opportunities to malicious actors to infect the equipment that creates a connected machine.

Governments are driving much of the public attention on IoT security. And rightly so! They need to establish the regulations and programs to ensure that the connected systems supporting critical infrastructure have not been compromised. In fact, the U.S. government has already banned installations on U.S. soil of video cameras and cellular network infrastructure from a select set of suppliers.

In 2023, the Federal Communications Commission (FCC) issued an inquiry questioning the security of cellular modules. Cellular modules provide the radio interface for sending and receiving data to a device over a cellular network. The importance of cellular module security in IoT solutions will grow as 5G and industrial Internet solutions expand into the market. In the first of a series of articles covering cellular IoT module security, we examine the role of security in the module design and manufacturing process.

Role of a Cellular Module in a Connected Cellular Device

Cellular modules are one of multiple components on a Printed Circuit Board (PCB) that enable computing and communications. On one side, the module is connected to antenna components for transmission and reception of data to/from the cellular network. On the other side, it is connected to an application processor, a Microcontroller Unit (MCU), that is the brains of the intelligent device. The application processor is responsible for all the computing activities on a device and for directing use of other components such as the cellular module for data communications.

There is a well-established cellular module supplier market with over 30 suppliers worldwide. Cellular modules are a preferred choice for adding cellular communications to a device or machine for reasons of cost, time to market, and human resources investment.

Related Blog:  What is a Cellular IoT Module and What are its Capabilities?

Development and Manufacturing of a Cellular Module…Securely

The foundation of cellular module security is the chipset platform on which the module is built. There are several suppliers of cellular chipsets, including Qualcomm, Sony Semiconductor, Sequans, MediaTek, ASR, and UNISOC; Qualcomm is the leading provider with an estimated market share of around 70%. Within the chipset platform are the four critical building blocks driving the module’s security capabilities.

The first building block, the Trusted Execution Environment (TEE), is a hardware-isolated space within the chipset processor, which also includes its own Operating System (OS). Within the TEE is the second critical building block, secure storage, memory that cannot be overwritten holding critical security applications and functions. Stored within secure storage for execution within the TEE are secure applications, the third building block, such as a secure boot loader, and the Transport Layer Socket (TLS) application. Finally, the fourth critical building block is the root of trust, the hardwired, immutable fuses that hold the private keys/hash values identifying the device and required to authenticate trusted entities wishing to update module firmware.

Using these building blocks, module vendors align a community of suppliers to create holistic module security covering partners, practices, and processes. The following sections provide a more detailed review of important elements in the cellular module value chain that ensure not only secure module development, but also security in the module manufacturing process.

1. Secure Design

2. Secure design happens at the development phase. It is a formalized, controlled approach for building in security at the inception of product development. Secure development is also known as DevSecOps, and is a method used by hardware and software developers to integrate security in all phases of product development, in both hardware and software, using security testing tools, workbenches, Integrated Development Environments (IDEs), build tools, and debuggers.

• Trusted Hardware Development: The hardware of the module must be designed securely from a physical perspective. It should include anti-tampering qualities to avoid side channel attacks or differential power attacks so that it can detect any physical attempts to alter the hardware or pull sensitive data from it. Hardware features that prevent side channel attacks are typically provided by the module’s chipset vendor.
• Trusted Firmware/Software Development: Secure software/firmware development includes the incorporation of practices for risk assessment, vulnerability checking, code scanning, software component analysis, static and dynamic application testing, change tracking and logging, source control, continuous validation, access controls, code signing, secure boot, and authentication/authorization.

For cellular modules, these practices apply most to firmware development. The firmware of a cellular module is a software program that operates the module. This component is provided by the radio chipset vendor; however, module vendors will add additional features to the firmware. Much of the module vendor development will be in extending the Application Programming Interface (API), including creating new AT commands; today, AT commands are the primary communications protocol between the MCU and the module. New AT commands could include those to improve module energy use, or for remote communications customization such as changing the data communications interface from Universal Serial Bus (USB) to Peripheral Component Interconnect (PCI). Commands may also be added to aid in manufacturing, testing, and calibrating the module.

APIs are another area of module software development seeing some early use as a replacement for AT commands. APIs are small pieces of software made available by an application to enable communications with other systems, cloud services, and other applications. Traditionally, APIs are designed for larger compute devices using OS software such as Android, Apple, and Microsoft, and are typically used for communications between the MCU and the cloud.

Integrity of the final software package is an area where there has been increasing activity by module vendors. For example, module firmware can be examined by a third party contracted to scan the source code and/or the binary files for vulnerabilities. Another approach is making the Software Bill of Materials (SBOM) available for review.

The outcome of a secure development process is a cryptographically signed and trusted release package. This package includes the SBOM and if a third-party vulnerability testing firm is employed, a Vulnerability Exploitability eXchange File (VEX) file. The VEX file details the components in the package and any vulnerabilities/exploits that were identified, and confirms that remediation has occurred. What is most important is that the entire package has been cryptographically signed via a certification authority and/or with trusted public key infrastructure (for example, from the chipset Original Equipment Manufacturer (OEM)). The public key/certificate for the signed software is loaded by the OEM during the manufacturing stage, ensuring that only firmware signed by the private key (controlled by OEM or trusted third party) can be loaded and run on the device.

2. Secure Manufacturing

3. One of the most important processes that affect the security of a module is injecting the new module with its assets of credentials (such as its identifiers, cryptography keys, certificates), and firmware. This process erases the preproduction image on the new module. Whether for a smart OS (high compute device such as a gateway) or for a Real-Time Operating System (RTOS) (i.e., a small footprint device such as a sensor), the injection process must ensure that these assets have not been compromised in any way.

Security for the injection process includes secure communications channels to transfer the assets, secure programming equipment, and Hardware Security Modules (HSMs), which can all help minimize security risks in the manufacturing phase. Ideally, an HSM, which securely stores device credentials, is used in the injection process for credentials transfer, including delivery of a secure boot manager.

Another critical element of the firmware injection process comes from the silicon itself. The cryptographic hash of the firmware root certificate that forms the basis for future secure operations is “burned into” one-time programmable fuses in the silicon. It is a write-once operation and cannot be changed by another entity, including the module supplier.

Once this injection step is completed, the module and device have new firmware, a unique identifier, associated keys, and certificates that can be used further down the line for programming the device and later onboarding it to a secure service and providing secure updates post-market.

Targeting the firmware injection process to insert malware on new devices is one of the most common approaches used by hackers. This is why a security by design approach is the most effective way to create secure modules, including using trusted partners.

3. Vulnerability Testing

4. Vulnerability testing is a whole range of tests to identify vulnerabilities that a hacker could exploit to drive a threat, event such as an embedded kill switch. The tests cover security assessments on the module firmware source code, machine code and software containers, API testing, full device testing, and lifecycle threat monitoring.

The primary vulnerability tests applied to the cellular module cover two broad categories. The first is source code testing. Source code is the code used by the developer to write the firmware of the cellular module. Cellular module firmware is typically written in C. The OSs of module firmware vary by chipset provider, but common ones include Linux, ThreadX, and FreeRTOS.

Within source code testing are Static Application Security Testing (SAST) and Software Composition Analysis (SCA). SAST is applied as the code is developed with the intent to catch security issues early. SCA is an automated way to identify open-source code used in the firmware and check if this code has vulnerabilities. Two open-source code types used in module firmware are Libxml and cURL. Module vendors that employ SAST and SCA are testing the full package of source code, both the code provided by the chipset supplier and the code overlay added by the module supplier.

The second category of cellular module vulnerability testing applies to the machine code and is called binary scan testing. The machine code was created in the compilation process from the human-readable source code. The machine code, also called binary code, consists of a series of 1s and 0s, and is directly interpreted by the module OS. Binary scan testing is looking for unusual machine code patterns that indicate potential security threats. It checks the machine code for issues introduced by the compiler or determines if some of the binary outputs have been tampered with.

Container scanning can also be part of the security assessment if module software development includes delivering code via software containers. Container scanning verifies that these software units do not have security vulnerabilities and that the interaction of the container images with other software units and the module OS is not compromised. Module firmware is typically monolithic and developed as a single unit rather than consisting of multiple mini-software packages that work together, so container scanning is rarely necessary on module firmware.

The SAST, SCA, binary scan, and container scan tests complete the security analysis of the final module firmware package, and the results are placed in the VEX file.

Once the module is installed on a PCB to create the final device, including integrations to the MCU, antennas, and networking components, other security tests can be applied. Dynamic Application Security Testing (DAST) tests for vulnerabilities, while the cellular device communicates with server or cloud applications and databases. DAST attempts to mimic hacker attacks to find unknown vulnerabilities. One area that DAST services attempt to exploit in an IoT device are the TLS communications that happen between the cellular module and the MCU, and the module and cellular network.

API testing, which tests API code for vulnerabilities, is another part of security assessments, but mostly performed on the finished device with an IoT application. Finally, vulnerability/threat monitoring is a more comprehensive and continuous process for identifying, classifying, remediating, and mitigating vulnerabilities. It applies to the entire threat surface covering devices, applications, and cloud assets serving the IoT and non-IoT domains.

4. Trusted Partners

5. The core component of a cellular module is the chipset, which in the module industry is almost always provided by a supplier partner. It is critical that the chipset provider employs not only secure development practices, but also secure chipset manufacturing practices or uses a reputable contract manufacturing firm if outsourcing its chipset manufacturing. Chipset partners need to demonstrate many of the best practices and secure processes outlined above with the most important being secure facilities and secure injection processes.

As noted above, Qualcomm is the number one chipset supplier in the world with a 70% share of the IoT device market. Part of the reason for its large share is its reputation for secure firmware.

Security Standards and Regulation

There are no specific security standards that are applied to modules. However, there are standards development organizations and industry consortia that have developed guidelines for IoT device security that would apply to module manufacturing.

The most important standard is ITU X.509. It was developed by the International Telecommunication Union (ITU) and provides the standard for a public-key and certificate platform for open systems connection in the IoT.

Regulations are becoming a big driver for security of devices and applications. Leading the charge is the European Union (EU) with the European Cyber Resiliency Act (CRA). Passed by the European Parliament in March 2024, it aims to provide safeguards to improve the security of products and software sold within the EU that can connect to the Internet or with other devices. Those products that meet the CRA’s security requirements will receive a CE marking indicating they comply with the new standards.

The CRA will become enforceable sometime in 3Q 2027. To meet the CRA requirements, companies will need to conduct cyber risk assessments on their products not only before market introduction, but also throughout the product’s expected support period, which is up to 5 years (or longer if the expected lifecycle exceeds 5 years), to meet minimum cybersecurity standards. Noncompliance can result in fines of up to €15 million or 2.5% of a company’s total worldwide annual turnover from the preceding year, whichever is higher.

Governments around the world are actively considering new cybersecurity requirements for products used on public and private networks within the countries they govern. Given this increased scrutiny, cellular module suppliers will need to be more active in demonstrating how security has been designed into their products throughout the supply chain.

Summary

Today, cellular modules play an important role in cellular IoT solution security; in the future, module security will become even more important as 5G and industrial Internet solutions gain market share. Module security begins in its design and installation in device manufacturing.

For secure design, the foundation is the chipset platform that offers the tools, such as the TEE and root of trust, to enable module security throughout the device’s lifecycle. The chipset platform also includes the baseline firmware from which module vendors build the final firmware package. Critical to firmware development is using both secure software development best practices and vulnerability tests on the final firmware package, typically offered by a third party, to create added trust in the development process.

For manufacturing security, the core element is the firmware injection process. Preferably using an HSM, the firmware is securely loaded onto the module, and identity credentials are burned into the chipset root of trust.

Weaved within secure design and manufacturing are the use of trusted partners. These partners should have credentials that demonstrate their alignment with secure processes, either from customers, third-party validation organizations, and/or security standards certification for software development and manufacturing.

With over 400 million cellular modules shipped in 2024 and an estimated 800 million modules shipped in 2030, cellular IoT solutions need secure devices built from securely designed and manufactured cellular modules. But IoT solution security does not stop here, with the cellular module contributing to the connected product’s security over its lifecycle. Future articles will assess the role of cellular modules in important IoT security topics, including device management and the evolving security regulations landscape.

Related Blog:  What is a Cellular IoT Module and What are its Capabilities?