Advertisement

Meeting the security challenges in 5G gateway storage

The introduction of 5G gateways into IIoT environments highlights the need for a secure boot system based on root of trust

The adoption of the internet of things (IoT) in Industry 4.0 means an increasing number of connected systems, ranging from simple sensors and actuators to nuclear power stations. Ensuring the security of these is essential for correct operation and safety. There are many types of threat from different sources: random hackers, criminal groups, commercial espionage, and state actors. If a device is compromised its operation may be affected and it can no longer be trusted for data exchange, processing, or storage. This is a particular danger for 5G communications gateways, where a vulnerability could expose the entire system to attack.

Industry 4.0 applications

Range of connectivity in Industry 4.0. Click for a larger image. (Source: Hyperstone)

The introduction of 5G gateways into industrial IoT (IIoT) environments highlights the need for secure boot based on a “root of trust”, i.e. software that can be guaranteed not to have been compromised. In particular, the code executed by a microcontroller must be trusted to ensure secure operation. This requirement will influence design choices for storage subsystems.

5G gateway in IIoT

5G connectivity and Industry 4.0. Click for a larger image. (Source: Hyperstone)

Vulnerabilities in embedded systems
As well as the usual need to protect against phishing, malware, and other standard attempts to breach the security of internet-enabled systems, there are also some more specific challenges faced by embedded systems. This means that security needs to be “layered”: considered at all levels of the system and designed into the hardware.

At the highest levels, human factors need to be considered. The application software layer will provide data encryption and user authentication. At the lowest level, storage must support secure boot and validation of firmware updates.

The only solution to an attack that involves physical access to the hardware is for the microcontroller to execute code from internal read-only memory. This is, by definition, secure and forms the root of trust. However, microcontrollers have moved away from having fixed firmware in read-only memory on the chip to using non-volatile memory for code storage, typically NAND flash. This is more flexible than read-only memory and enables live over-the-air (OTA) updates of software – essential for both functional changes and security fixes. But the ability to install new software presents another potential attack surface.

Ensuring that the code in non-volatile storage is secure, requires a secure boot system that can check both the integrity and authenticity of the code. Integrity means that the code has not been modified, either by accidental corruption or by malicious tampering, while authenticity means that you can be confident that the code is from a trusted source.

These checks can be applied at boot time before the code is executed, and also to firmware updates before they are applied.

A brief history of public-key cryptography
Secure boot relies on public-key cryptographic techniques to sign and verify the software.
Encryption systems were originally symmetrical: they used the same password or key to both encrypt and decrypt a message. This has a single point of weakness; the key has to be shared between all those communicating and if a third party obtains a copy, they can intercept, read, and potentially modify any message.

Modern cryptography uses asymmetric, public-key algorithms. Here, two keys are used: one is kept secret and the other can be made widely available. Messages can be encrypted with one key and decrypted with the other. This eliminates the problems of securely distributing encryption keys.

Public-key cryptography can be used in various ways. For example, a message encrypted with the public key can only be read by the owner of the corresponding private key and so it is safe to transmit it over an unsecured network.

Alternatively, a message encoded with a private key can be read by anyone with the associated public key, but they can be certain that the message did, in fact, come from the correct source (no one else would be able to generate a message that can be decoded with that public key). This is the basis of digital signatures used to authenticate messages.

Rather than encrypting the entire message, however, a shorter message digest or hash is generated using an algorithm such as SHA-256. This uniquely identifies the message and can be used to verify its integrity. Then, to ensure the hash itself is correct, it is encrypted with the vendor’s private key. In this way, the authenticity of the signature and, therefore, the message can be confirmed. Although it is possible (but extremely unlikely) that two different messages could generate the same hash by chance, it is practically impossible to modify an existing message in such a way that it will have the same hash as the original.

This same principle can be used to sign executable code: both the application code that is executed after the system boots and any OTA updates received.

Using public-key cryptography to secure the boot process
At power-on, the microcontroller starts by executing code from internal memory. The main task of this boot code, after any necessary initialization of the system, is to validate the application code in the external flash before executing it.

A digital certificate is used to validate the public keys from the software vendors, otherwise malicious software could be installed by using a fake public key. Manufacturers can “self certify” by simply creating this certificate themselves. Or, for greater security, they can use the public key infrastructure (PKI), which uses a hierarchy of certificates that ultimately rely on one issued by a trusted Certificate Authority (CA).

Implementing secure boot
The boot code and the certificate must be stored in a secure location on the chip that cannot be modified. This ensures that the boot code can be trusted and the certificate cannot be replaced by one that would allow the security to be compromised.

This can be flash memory internal to the microcontroller, as long as suitable on-chip security exists. This can use a fuse that physically prevents further writes to the flash memory once the initial software has been programmed. Or it can use an authentication mechanism that only allows authorized updates to the root-of-trust software.

There are several different algorithms used for generating hashes and for public-key cryptography. Some of these are computationally expensive and may require hardware acceleration to avoid impacting the performance of the storage system.

A high-performance flash controller is required to ensure that the security requirements do not impact system performance. It must be capable of implementing the algorithms directly or of providing support for appropriate co-processors. Custom firmware extensions should allow this extra functionality to be added as a fully integrated part of the controller firmware, while still being completely under the control of the storage system developer.

Conclusion
For security in 5G industrial gateways, a secure boot system must be implemented to provide a root of trust between the controller and the non-volatile storage where the application code is stored.

For an industrial 5G gateway to meet all necessary performance and reliability requirements, the right industrial-grade storage technology must be selected. The choice of the flash memory controller in the 5G storage system is crucial, as it determines the performance, reliability, and extensibility of the system.

With extensive experience in delivering high-performance, secure, and reliable storage solutions, Hyperstone is ready to discuss any aspects of secure boot and non-volatile storage as they relate to creating a 5G industrial gateway.

About the author

Meeting the security challenges in 5G gateway storageAxel Mehnert is responsible for marketing, product strategy, and business development across product lines and market segments at Hyperstone. He has been involved with the Flash industry for over 15 years. Before joining Hyperstone, he held various positions at technology and semiconductor companies in product marketing, sales, and strategic planning with Siemens, Evergreen Technologies, and Texas Instruments. He holds a BS in economics from Kiel-University, Germany and an MBA from Oregon State University.

Advertisement

Leave a Reply