Authors: Jim Wallace, Arm; Joseph Byrne, NXP
It’s hard to imagine a day without relying on a computer or smartphone at work, when shopping or banking, chatting with friends, or even listening to music or watching a show. At the same time, it’s hard not to feel a twinge of vulnerability when headlines proclaim news of a massive theft of credit card data, hospital operations being held up for ransom, or access to a popular website being denied.
The attack surface continues to grow as we become more connected, and trust elements such as security, resilience and privacy will need to be built into next-generation smart edge devices, networks and data centers to reduce vulnerabilities and realise the benefits of our hyper connected world.
Security technology, one of the fundamental building blocks in SoC design, and the security model triad of confidentiality, integrity, and availability (AIC) are essential to ensuring trust. This AIC model includes encryption for data confidentiality and user authentication, packet processing to help with system availability and integrity, and platform trust for system integrity.
This blog will focus on some of the key technologies needed to protect network access, availability and data, with a brief overview of Arm’s underlying platform that is providing the foundation for trust.
Figure 1 Network security; successive layers providing a greater degree of protection
At the perimeter of the network, access control plays the main role in reducing simple security attacks. Basic packet filtering and rate limiting combine to mitigate denial of service (DoS) flooding-attacks before packets can enter the next firewall security layer. Firewalls deliver additional access control by filtering traffic that does not conform to the network's stated security policy. They incorporate techniques for reconnaissance deterrence (e.g. ping sweeps, proxy scans, packet sniffing etc), and deep packet inspection [i] with Intrusion Detection and Prevention (IDPS) capabilities.
At the innermost layer, network nodes, which can receive, create, store or send data along distributed network routes, provide further access control measures and support more sophisticated means of protection, often referred to as ‘node hardening’. Node hardening tries to ensure that a node is secure by default and can then remotely attest to its authenticity and security state so that other nodes can trust it. It does this by embedding roots of trust in hardware, which provides the foundation for patching and updating software, securing running services, controlling node access, minimizing the number of system services running, while ensuring all activities are logged and that configurations are backed up.
Security always starts with the node and key elements in the security chain are then built on top of this. Encryption using cryptographic techniques is one of the crucial links in this security chain.
Although encryption can protect data at rest, most often it protects data in transit over the network. Crypto instructions have been added to the Armv8 architecture to accelerate cryptographic algorithm execution on the CPU. The Arm Cortex-A72, an Armv8 processor, has new instructions to accelerate AES, SHA1 and SHA2-256 algorithms. Network security protocols, such as IPsec and SSL/TLS commonly use these algorithms. Compared with earlier Arm CPUs, the new instructions and other enhancements enable the Cortex-A72 CPU to significantly improve algorithm execution. NXP has found that its LS2088A processor with eight Cortex-A72 cores and accelerators can run the SSL-based HTTPS protocol faster than a non-Arm based eight-thread competing chip.
Figure 2 NXP Layerscape LS2088A eight- core processor based on Arm Cortex-A72 CPU.
Using a CPU for encryption is convenient for a programmer. VPN software, for example, can move from control processing to encryption with a simple function call. A lookaside accelerator requires the software to shuttle cleartext data to it and find something to occupy the CPU while waiting for the accelerator to send back the encrypted data. The crypto unit in NXP’s Layerscape processors is clever enough to process packet headers and trailers in addition to encryption, reducing the number of data transfers.
The company’s Layerscape LS2088A processor is even smarter. Endowed with a C-programmable packet engine, it can fully offload the popular VPN protocol IPsec at 20Gbps for 128-byte packets—a performance boost that also frees the CPUs for other tasks. This engine can also accelerate NetFlow, a program for gathering statistics about what’s happening on the network. One use for these statistics is security, such as using algorithms instead of signatures to assess whether flows are a threat to the integrity of the network and the systems connected to it. The engine can also offload iptables, the basic firewall function built into Linux.
Trust starts with network node devices that have hardware-based trust anchors (known as roots of trust), a trusted boot process to get those systems into a known good state and layers of hardware and software-based security that can be used for lifecycle management, authentication and firmware and software updates.
To enable this trust foundation, Arm provides a range of platform specifications to standardise best practices – for example, the Trusted Base System Architecture (TBSA) defines hardware requirements for security functionality in TrustZone-based systems and the Trusted Board Boot Requirements (TBBR) defines a secure boot process.
Figure 3 Arm builds layers of hardware security - Hierarchy of Trust
There are 4 layers in the Arm security architecture, which provide increasing levels of security. As we go up the triangle we increase security by increasing the level of isolation and compartmentalization. Arm uses the principle of least privilege that states code should have the least privilege necessary to perform the required function.
Starting at the base of the triangle we have a separation between the Application and the OS through a combination of the MMU and the OS. This uses Exception Level 0 (EL0) for user code and EL1 for the kernel in the normal world. Running processes or applications are isolated from each other by the operating system and the MMU. Each executing process has its own address space, isolated from other processes, along with a set of capabilities and permissions that are administered by the operating system kernel, which executes at EL1.
A potential weakness with this approach is that the kernel can peek into any process’s memory. Linux provides the ptrace call (which can be disabled) and Windows provides the ReadProcessMemory call that enable one process to see another process’s memory. The latter was used to swipe credit card details from the sales terminals of American retailer Target and ransomware like NotPetya.
Virtualization overcomes this by adding another layer of isolation, enabling one CPU to host multiple OSs, each unaware of the other. In the normal world, the Hypervisor protected domain runs at EL2 and allows multiple instances of the same or different operating systems to execute on the same or multiple processor as a Virtual Machine. Each virtual machine is isolated from the others, and through the use of a System MMU, such as the MMU-600, other bus masters can also be virtualised. This separation can be used to protect and secure resources and assets in one virtual machine from other virtual machines.
To ensure optimal performance, Arm has added dedicated Virtual Machine Management (VMM) hardware extensions to accelerate switching between virtual machines and hypervisor software.
The Trusted/ Secure World is a hardware isolated execution space aimed at hosting a small code base and therefore has a much smaller attack surface. Using the TrustZone security extensions, allows the system to be physically partitioned into secure and non-secure components. This enables a Trusted Execution Environment (TEE) to offer secure services to the normal world without the normal world being able to access any of the secure world resources - for example, secure memory or secure peripherals.
Arm’s CryptoCell augments TrustZone and further fortifies device security. The multi-layered hardware and middleware architecture combines hardware accelerators, root-of-trust control hardware with a rich layer of security middleware that runs in TEE.
Finally, we have the Secure Element (SE) or subsystem with a much smaller attack surface and very limited code, that can be an on or off-chip implementation.
Secure Elements, with hardware backed services, are more secure as there is less sharing of resources. A physically separate CPU with separate memory has a smaller attack surface than the secure state of a shared CPU.
Security subsystems such as Arm’s CryptoIsland, or NXP’s Trust manager provide a range of security services including persistent storage of secrets and secure key management, validation of loaded software, validation of software updates, rollback prevention for code and data, cryptography, strong authentication of parties prior to giving them access to resources, and more.
These services, in the Secure Element, also need to be augmented by secure code running in the Trustzone TEE to securely invoke the function in the SE and provide a secure path to receive and send data to the normal world.
Figure 4 Hardware, firmware and software security resources
The value of connecting the next trillion devices will arise from the seamless flow of trusted data between devices. Security must be a primary design consideration in these next generation networks— always present and securely updateable as the threat model changes. It needs to start at the earliest possible point, within the SoC.
Securing tomorrow’s vision means rethinking how we design intelligent devices and networks by embracing new concepts from outside the digital realm and taking advantage of advanced new technologies.
Arm and the Arm partnership are actively engaged in this, building and providing the foundation to enable you to build your security framework for these next-generation networks and services.
[i] Note: for ordinary encrypted packets, it is not possible to do deep packet inspection. Most devices that do deep packet inspection of encrypted streams do some kind of intercept and decrypt along the way.
Joseph Byrne is a senior strategic marketing manager for NXP's Digital Networking Group. He blogs about edge computing and security.
Very informative post especially for businesses who provides IoT solutions to keep the data safe and secure.Thanks for sharing it with us.