Root-of-Trust for IoT and Other IoT Security Trends

The topic of information security is becoming increasingly relevant every year. The information security hub is in first place in the rating and second in the number of subscribers. However, the materials are mainly devoted to various network, web, cloud and other technologies traditionally considered in the context of security. And almost do not apply to embedded applications, especially with limited resources. While the number of the latter is more than orders of magnitude. In this article, we will look at some of the features and trends in the security of the Internet of things that have their origin in the development and distribution model.


Development for embedded applications has always carried certain features, moreover, such that most "ordinary" programmers do not even think about it, and the concept of QA and the testing process in many cases are fundamentally different from what is generally understood.

One of the favorite and periodically discussed topics in the large IT channel in the Telegram Embedded Group is “why nobody understands embedded developers and pay so little? (against the background of "ordinary" programmers) ":) An

embedded system is a system that will work by being built directly into the device that it controls. A couple of photos for clarity:



The left image is taken from a Wikipedia article about embedded systems, is an example of a large complex system. On the right is a photo from the review of the Redmond smart home , everything is much simpler and more compact here, in fact the whole device is made on one chip with minimal binding. It is important that both devices function as complete devices (a single-board computer still needs a case and some peripherals).

As a rule, a manufacturer company produces finished devices, which primarily includes hardware, and software, as a rule, is bundled and works only on this hardware. Almost no one would have the idea of ​​buying a “bare” smartphone without software, and then installing on the OS and the necessary applications, everything should work out of the box. As a result, developers often perform the entire spectrum of tasks for the development of devices, both software and hardware.

Another feature of development for embedded systems is that they almost always have much less resources, both in computing power and memory, data channel, as well as consumption. Most of the technologies familiar to many are impossible to run on such systems, even the OS is not everywhere. It is necessary to fit into the available resources and often save significantly. This also affects security - many standards from the Big World are not supported or are supported with restrictions.

C is still the most widely used language for developing embedded systems. It has a number of shortcomings in working with memory that directly affect security. To solve them, Rust was developed , it is gaining popularity (in the first place of your favorite languageson StackOverflow for several years, overtaking even Python and Kotlin, especially popular recently), but still far from the leader in applicability in embedded because of the supported systems and libraries. Higher-level languages ​​are rare for embedded systems and are likely to remain so soon.

An important feature of the development of embedded systems is the limitation of the hardware capabilities of the platform and SDK supplied by the manufacturer. It is simply impossible or extremely costly to implement many technologies on their own from scratch for a single project. Therefore, it is imperative that the chip manufacturer supports state-of-the-art security technologies. Until recently, so much attention was paid to this. For example, if the hardware AES appeared quite a long time ago at almost everyone, then many people still do not know how to support TLS / DTLS. The question is how to achieve this. I recently wrote about the new Nordic Zephyr SDK that solves this problem by integrating with a large project supported by the Linux Foundation. This is one approach. Below we will consider others.

As part of the consideration of the security of embedded systems, it is necessary to note a group of applications that fall under the requirements of functional safety standards: medicine, automotive, railway equipment, industrial automation. These are applications that directly affect the life and health of a person, as well as for systems that cannot be stopped (for example, a nuclear reactor). Here everything is clearly regulated at all stages of development and the potential for failure and the effect on the operation of the system as a whole are taken into account. Development is carried out on specialized hardware and software solutions, which in the future also need to be certified. As a result, it turns out long and expensive. Therefore, those who begin development do not think about it if there are no binding standards.

We recommend a series of articles on functional safety for review .

In addition to the development issue, it is important to pay attention to the operating conditions of the systems.

As a rule, large companies, manufacturers of cloud services care about the security of their services for a number of reasons:

• They are engaged in the development and support of the functioning of the service directly
• They have much closer contact between developers and support engineers.
• The equipment is directly accessible to engineers, even if in the clouds
• Wide data transmission channels and high computational ability of the equipment allows the use of monitoring systems and detection of abnormal activity

Devices of the Internet of things work in exactly the opposite way:

• As a rule, they are the property of the end customer, and the end customer engineers, competencies, which in most cases are inferior for objective reasons, are engaged in the configuration and support.
• The resources of each device are limited, both in terms of performance and data transfer. As a result, a system for monitoring and detecting abnormal activity is practically impossible in this case.

For clarity, I will give a comparative table. Immediately make a reservation that:

• There are many software delivery and support options. Only general groups are given for illustrative purposes.
• The number of devices of the Internet of things is difficult to estimate accurately, since everyone understands something different under it, and there are also no good statistics on them.

	Servers and cloud solutions (SaaS and the like)	User devices (PCs, smartphones, etc.)	Internet of things
Who is developing?	solution provider	-	-
/ ?
/?
		—
			,
	()		( )
	(Amazon, Google)	2019 : ~266 K, ~1.37	9

As a result, situations periodically happen that the devices were hacked, and nothing is known about this for objective reasons. Unfortunately, this situation is not uncommon and can last for months, and sometimes for years.

The most famous hacks of embedded systems in recent years:

• Mirai botnet in 2016, working mainly on camcorders. According to various estimates, the number of infected devices exceeded 380 thousand . His successor Satori in 2018 has already captured 700 thousand devices, focusing primarily on cryptocurrency miners.
• KRACK hit WPA2 Wi-Fi in 2017 (almost all Wi-Fi devices in the last 15 years) and its heir Kr00k , with more than a billion devices in 2019.
• In 2018, Bleedingbit hit Texas Instruments BLE chips. Officially, only a few access point models that used the CC26xx family were affected, and the problem itself was solved in the new version of the stack. However, in this case, it is not taken into account that these chips are used in a much larger number of devices (the second-largest producer of BLE in the world, 16% of 3.9 billion for 2018).

Most hardware manufacturers release patches for their devices. However, these corrections must still be applied on the devices themselves, which is difficult or in some cases impossible for devices of the Internet of things. As a result, a significant part of the devices remains potentially vulnerable. And they may never learn about this because of the lack of control and due attention to this issue.

Accordingly, it is necessary to use fundamentally different approaches to prevent vulnerabilities and eliminate the consequences for Internet of things devices. Security must lie in the platform itself from the very stage of its design and be carried out at all stages of development and operation of the end device, but at the same time be simple and inexpensive for mass implementation (at least with respect to functional security and TEE of powerful processors).

ARM in 2017 talked about the security of embedded systems based on CryptoCell and Cortex-M33, however, serial samples of chips on the M33 appeared only last year. The presented technology is called Platform Security Architecture (PSA).


The essence of the idea was to separate critical parts of the system (keys, rights, firmware) from potentially hackable components, both hardware and software, for systems where the full implementation of TEE is impossible or difficult. The technology is primarily focused on Cortex-M, but is compatible with all Cortex-A / -R / -M families.



Basically consider 4 stages of protection of devices of the Internet of things. Consider them in sequence as they arise during the operation of the device.

Secure Boot

• It is verified that the firmware is genuine, has not been changed, and cannot be downgraded.

Secure firmware update over the air (Secure FOTA)

• Only authenticated and verified updates can be downloaded.
• ( )

API

• , .
• «» API.
• —

• (MITM)

To protect the device, it is proposed to identify / verify data arriving at each stage. The concept is based on the idea of ​​the root of trust (Root-of-Trust, RoT). The bottom line is that a certain identifier (key) is sewn into the device and a hardware procedure is going on to verify that the key is unique to the current platform and the executable code. In the future, all important libraries use RoT for their own work.


Typically, this occurs in 3 main stages:

1. Providing trust: inclusion of the Root-of-Trust at the production stage in the chip structure. The
   immutable chip identifier and the hardware root of trust provide basic security and unique identification of the device.
2. :
   ,
3. :
   , 2 .

The most common solution on the market is ARM's TrustZone. Quite a lot has been written about its implementation on Habré, since the technology itself was introduced for a long time. The most clearly in my opinion was summarized in one of the latest publications .

In the context of this article, it is worth noting that earlier TrustZone was the privilege of high-performance processors of the Cortex-A family. And over the past year, almost all manufacturers of crystal-based wireless systems have released Cortex-M- based solutions ; the most popular is Cortex-M33 .

Speaking about information security, it is worth recalling the system of general criteria(Common Criteria), adopted both internationally and as a national standard. It allows you to determine the level of trust Evaluation Assurance Level (EAL) from 1 to 7 (EAL1 - EAL7), a higher figure indicates a higher level of security. To understand, the majority of Windows operating systems have an EAL4 or EAL4 + level , LInux / Unix, EAL5 basically have smart cards (banking, transport, including contactless), EAL6 allows you to use the solution in high-risk situations, EAL7 in extreme risk situations, for example, for unidirectional networks (data diodes).

In April of this year, the Cortex-M33 and M35P were certified to EAL6 +. This is a very high level that allows you to apply solutions in high-risk situations.

ARM TrustZone Cryptocell in the new Cortex-M33 / M23 provides secure key storage (including one with a unique hardware identifier), firmware checking, both during the download and update over the air, hardware encryption acceleration AES, SHA, ChaCha, ECC, in including with DMA (as a result, all data in Flash and RAM can be encrypted), random number generators (TRNG, PRNG).


It’s interesting to note that CryptoCell allows you to have several roots of trust for various tasks (for example, embed an additional RoT for a customer who wants to integrate a mass solution from the market into his closed IT system, for example, a bank without being tied to the main RoT from the manufacturer), as well as secure debugging (Secure Debug) with authorization rights.

The 300 series of CryptoCell is targeted specifically at low-power Internet of Things devices. The consumption of the new M33 is approximately 20-40% lower than that of the M4, given the loss in energy consumption for TrustZone's work of 20%, we have the same or lower consumption level than now. As a result, we can say that hardware security has come to the most massive budget segment with the Cortex-M33 / M23 and in the near future the number of products based on them will only increase.

TrustZone alternatives include OpenTitan sponsored by Google. However, it is not yet widespread and focused on other applications than end devices of the Internet of things.

It is worth noting that the hardware implementation of the root of trust is not a panacea and can also be hacked. An example is the recent story with Intel . It is important to mention that in this case an error was found in ROM and one key was used for all generations of chipsets, therefore it can be reproduced. And even such an implementation greatly complicates the hack.

Consider the 5 stages of the evolution of the implementation of Root-of-Trust in the uBlox cellular communication modules , developed in collaboration with the Kudelski Group. This is interesting from the point of view of the task, since their solutions differ significantly from the approaches of other companies. Cat-M Nb-IoT / LTE cellular modules belong to the transition classes between the 4th and 5th generations of LTE and are aimed at low-power LPWAN networks. In most cases, devices should work for years without human intervention. Modern solutions allow you to work 7-10 years on one battery (battery). The average life of the device often reaches 15 years. During this time, security requirements may change significantly, new threats will appear. Devices should work stably without human intervention for the entire service life. Accordingly, it is necessary to protect such devices taking into account the duration and nature of their work.


As you can see on the structure, with each next generation, the root of trust changes its position. This is a key point affecting the security of the solution as a whole.

Options 1 and 3 are considered unreliable according to uBlox / Kudelski due to the software implementation of RoT and the most likely hack. Including for the case of making the root of trust in the external eSIM (eUICC), which provides sufficient protection for banking applications of entry-level EAL4 (keys in eUICC cannot be read or changed so that it does not become visible from the outside). However, this approach brings with it flaws and potential vulnerabilities arising from the fact that communication with an external component can be intercepted and potentially distort, the complexity of interaction at the initial stages of system initialization (bootloader verification), as well ascomplicated programming mechanism due to limited chip resources in UICC. In addition, the external module can be replaced or removed from the system (simply by changing the SIM card) and thereby leaving the entire system without a root of trust.

Therefore, the further development path is to integrate the root of trust in the protected area of ​​the chip. This approach is consistent with ARM TrustZone CryptoCell Composition.

The version with the implementation of Root-of-Trust in a secure OS is the most common on the market and provides a level of security sufficient for most tasks. The most common solution on the market is ARM TrustZone (about it above), but without CryptoCell, which stores keys in a protected area.

The solution with protection integrated inside the chipset, to which there is practically no access from the outside, has the greatest protection. The current solution uses the built-in security element (Secure Element), certified according to the EAL5 + level . This allows Common Criteria certification for the entire device as a whole, and also allows you to place SIM card functions and Mobile Network Operator (MNO) profiles within the device. This corresponds to the current level of security.

The next generation of the uBlox chipset is under development, where Secure Element will be integrated into the silicon of the modem chipset itself. This further reduces the attack surface and improves security to the highest level. It will be implemented through iUICC(Integrated Universal Integrated Circuit Card) - the next generation of UICC, in which the entire code and SIM identifier will be located inside the system on a chip, the standard has not yet been completed.

Findings:

• More and more manufacturers of electronic components develop and produce devices with security in mind, starting from the earliest stages of development.
• Endpoint companies get security management tools right out of the box. Attracting experts at the stage of developing tools allows you to avoid mistakes, as well as significantly reduce the cost of the solution as a whole.
• The price tag for new solutions is often close to current solutions, but gives a fundamentally different level of protection, which also greatly simplifies the transition
• The growing number of devices providing a new level of security is only a matter of time.
• In new secure element solutions, UICC is transferred inside the chip chip to increase security and hinder attacks
• Modern solutions provide security levels up to EAL6 + sufficient for use in high-risk situations.
• Solutions of the EAL7 level are under development, however, they use technologies without a finally approved standard, therefore the term for their market availability is not defined.