Power/Performance Costs Of Securing Systems

For much of the chip industry, concerns about security are relatively new, but the requirement for protecting semiconductor devices is becoming pervasive.

Unfortunately for many industries, that lesson has been learned the hard way. Security breaches have led to the loss of sensitive data, ransomware attacks that lock up data, theft of intellectual property or financial resources, and loss of control of facilities and equipment, to name a few.

But protecting devices does not come for free, and how much protection is needed depends upon such factors as the value of the system and data, and the vertical market segment. That can make it difficult when designing a chip or system because it isn’t always obvious how the device will be used, particularly if it is integrated into a larger system. Adding too much protection has a cost. It is likely to be slower and consume more power than a device that is not as well protected. The total financial impact of adding security is difficult to measure, but massive amounts of power and performance are lost to make systems secure.

“One way to consider power loss is in terms of electrical energy,” says Brad Jolly, senior applications engineer at Keysight Technologies. “A study from late 2021 estimated the electricity consumed by cybersecurity to be approximately 300 terawatt-hours (TWh). The same study pegged the total world electricity consumption at 25,000 TWh, so the 300 TWh consumed by cybersecurity is more than 1% of total worldwide electricity usage. In terms of computing power (performance), I would expect the loss to be far more than 1%.”

Those percentages likely will increase over time. “I would expect four trends to make the situation ever more challenging,” adds Jolly. “First, the sheer volume of data being presented for encryption and decryption has increased. Studies have shown an exponential increase in CPU load as data sizes increased. Second, the awareness of the cost of cyberattacks like ransomware has driven businesses and consumers to increase their spending on cybersecurity. Third, the cybersecurity attack surface has increased dramatically, thanks to the growth of the IoT, the increased use of wearable and implanted medical devices, and the increasing connectivity associated with technologies like 5G, autonomous vehicles, and remote medical care. Finally, the increasing regulatory emphasis on cybersecurity, such as the Food and Drug Administration’s recent guidelines around cybersecurity in medical devices, will continue to drive cybersecurity engineering for the foreseeable future.”

Balancing cost and security
Security comes down to what to protect and from whom. “The value of the ‘what’ and the capabilities of the ‘who’ decide how much investment should be put into the security measures in a device,” says Carl Shaw, safety and security architect for Codasip. “Investment comes in many forms — expertise, time, tooling, power, performance, and silicon area, to name just a few. These can all be balanced against each other, but the final balance comes down to the perspective of the customer and what they are willing to pay for the level of security that they expect. Customers don’t necessarily value the security of the manufacturer’s assets, so they won’t accept a slower or more expensive product. But if they perceive their safety is at risk, they are willing to pay more.”

Risk assessment is vital. “The cost of a solution should always be considered side by side with the cost of an unresolved incident,” says Nir Tasher, TrustME secure flash technology executive for Winbond. “The cost of a widespread security breach or wide-scale attack can be catastrophic, with unbearable effect on business and society. It can bring down major companies, financial institutions, and even governmental agencies. As such, the cost tradeoff should not be taken lightly. Investment in security, both initially at design time, and later on in running costs, can prevent huge expenses due to security incidents.”

Some industries, such as automotive, are demanding more secure systems. “It’s important to protect the people driving the car and the car itself,” says Dana Neustadter, director of product management for the Solutions Group at Synopsys. “An automotive hardware security module can go anywhere from 1 million gates to over 3 million gates. Performance-wise, we can be looking at solutions that have multi-gigabit per second type of throughputs. The area and power will be influenced because of the amount of processing dedicated to encryption and authentication. There are performance, area, and power tradeoffs, but also security-level tradeoffs, especially for automotive. You really don’t have a choice. You pay the price because otherwise the car will not be safe and secure in the field.”

Standards often define exactly what is expected. “Automotive is becoming better-defined because now there’s a responsibility on the part of manufacturers to comply with ISO 21434,” says Mike Borza, scientist for Synopsys. “That has helped to clarify the basic requirements. In other spaces, such as IoT, the requirements are vague and more application-specific. IEEE P3164 (formerly Accellera SA-EDA) has just been formed, and it is designed to deal with vulnerabilities that might be introduced or present in third-party IP, and also as a means to provide transparency and clarity about what issues are mitigated in particular IPs, what issues are not mitigated in those IPs, and remain for the system integrator to deal with. That’s going to move things along, just as ISO 21434 has for security or ISO 26262 for automotive safety.”

For some, the tradeoff is more pragmatic. “If I implement AMBA CHI-E versus CHI-B, what’s the impact on power and performance between these two protocols?” asks Frank Schirrmeister, vice president of marketing at Arteris IP. “The only answer to that is, it depends. What volume of capabilities do you actually want to implement? We see increased attention to security-related things like MTE and MPAM, where you have memory tagging extensions. Those memory aspects come with protocols, and it’s a very simple consideration that the architect does: ‘If I have the memory tagging extensions enabled, I need more bits to transfer things.’ That has a very solid immediate impact that you can calculate in numbers, and quantify in an Excel table.”

Threat identification
It is impossible to know what protection to provide without first identifying the assets you have and the threats you wish to protect against. “Without this step, the added security may not be adequate, or could be overkill, both leading to higher overall costs,” says Winbond’s Tasher. “Once the assets and threats are identified and agreed upon, security solutions can be chosen. Focusing on hardware and lower software layers, and providing means for secure software updates, paves the way to overall lower costs and stronger security.”

Understanding use cases is essential. “What are you trying to protect, because this will influence how you look at the tradeoffs including cost,” says Synopsys’ Neustadter. “Are the use cases for the product only concerned with network-based threats, or could attackers gain physical access to the product? If there is direct network access to the product, or it’s protected by other parts of the systems that act as a firewall, the security mechanisms and implications will be different.”

Mitigation
Having identified the threats, mitigation strategies can be considered. “Similar to performance and power, security can mean multiple things and can come in different flavors and to varying degrees,” says Scott Best, senior director of product management for Security IP at Rambus. “Ensuring supply-chain security, for example, depends on authentication and attestation concepts, usually during manufacturing, and typically doesn’t impact mission-mode performance. Secure-boot is another example of security that. While not affecting runtime performance, it does affect system/OS/application startup times, as all software objects must be cryptographically measured and verified before they’re allowed to execute. There’s also data in use security, which may protect data in transit (e.g., across a network interface) or between a CPU and one of its memory subsystems (aka inline memory encryption). It is this type of security that can most noticeably bottleneck run-time performance.”

When a device is being created, it is not possible to know all the threats that may exist in the future. “A huge part of a security strategy is the ability to do over-the-air updates of firmware in these devices,” says Synopsys’ Borza. “Root of trust devices have a significant firmware component, and so the ability to update that firmware is one of the things that we use to ensure future proofness for new or emerging attacks. Anything that’s baked into the hardware that becomes exploitable is something that you can often mitigate in firmware updates, but you would like to design the hardware as much as possible to deal with security in depth. Even if you have attacks that you don’t know about, you have the ability to add some redundancy that can catch errors that might be induced at a later date, or as part of an attack. It’s often very good idea to incorporate that into the hardware at the outset. You don’t have a specific exploit in mind, but you can provide some redundancy at low cost that would pick up on those things.”

Attention to security never ends. “If you don’t know what that box is going to be going into, it’s really hard to prepare for those unknowns along that supply chain,” says John Hallman, DVT solutions manager at Siemens Digital Industries Software. “There have to be some contingencies that you can add along the supply chain, whether it’s in the chip, or maybe it’s later in the product itself, where you can make those upgrades. They could do a more global change to the function of your system, and be able to re re-evaluate your security profile later in the lifecycle of that particular product, and even the components of that product. That is a disruptive way of thinking of traditional build processes. That ability to be able to assess where you’re at, later in the cycle, and being able to adapt to the environment that’s around you is not necessarily a new concept. But it is a new concept when you think about how products have been built all the way up till now.”

Early planning
Security is not a bolt-on feature. “If you’re going to build in security protections, they do have to be planned early, and then verified as part of that early design,” says Siemens’ Hallman. “But they also have to be checked later. You need a methodology that not only inserts the mechanisms, verifies the mechanisms, and then assesses those mechanisms later when you have more information known about the end system. You don’t always know about that end system when the chip itself is being built.”

It is almost impossible to estimate the power and performance hit associated with adding security. “Security is not a simple commodity that can be evaluated,” says Tasher. “It’s a complex process that starts with the system requirements and definitions and goes through the entire life cycle until the system is being decommissioned. As a rule of thumb, the sooner security requirements are introduced into the system architecture, the cheaper and more efficient the solution will be. It is easier to protect the lower layers of the system (hardware, basic code loaders etc.) than protecting only the upper layers, such as user applications and data. Protection at the hardware level will be more efficient, as it is better tailored to the system operation. Good hardware and lower software layer security allows the system to survive and recover from software attacks and perform secure, timely updates with ease.”

Unfortunately, cost is not equal for all device types. “The cost is highest for the smallest, most constrained devices,” says Codasip’s Shaw. “Dedicated security hardware (or software) is proportionally larger, and the bandwidth overhead is greater for smaller messages.”

Still, the impact can be reduced with careful planning. “The impact to an SoC’s performance can be addressed by specialized circuitry, such as hardware-based public-key accelerators for improving startup times, and inline memory encryption engines for improving memory security,” says Rambus’ Best. “While both consume transistors and add to power consumption, it is a relatively tiny compared to the performance engines on the SoC itself.”

Hardware/software partitioning is an important consideration, as well. “Hardware-based security will always be cheaper in terms of running costs,” says Tasher. “It is up to the system designer to evaluate the possible solutions and provide the best mix of hardware and software protection layers given the usage profile of the system. As a rule of thumb, an initial investment in design and secure hardware will almost always pay off in the long run. The ability to remotely patch security vulnerabilities, for example, will cost less than $1 at production time, but will save lots of money during the lifetime of the system by eliminating the need to manually service each device and prevent potential business loss.”

But those considerations are not the same for everyone. “It depends on how fast you want to go,” says Nick Ilyadis, senior director of product planning for Achronix. “Things like Root of Trust require that you have the ability to run code that’s been encrypted and signed. It can be done inline using the CPUs instruction set, or it can be done with a hardware accelerator. Authentication typically uses elliptic curves, hash algorithms, things like that. Those are not that expensive because you’re only doing them on a chunk of the data. In-line encryption tends to get more expensive, especially at higher data rates, because to go faster, you have got to go parallel. Then you can start to chew up some real estate. There’s a performance aspect to it.”

It is important to understand all of the costs. “There is pressure with regulations, and device manufacturers are increasingly pushed to provide proof points that their IoT devices are secure,” says Neustadter. “If we look at IoT endpoints, they need to be secure and trustworthy. At a minimum, they should test the integrity and authenticity of their firmware and software, as well as take a reasonable response to a failure of those tests. In many cases, you don’t need a high level of performance. You may be able to create a secure environment in an IoT device, but you don’t need acceleration, and you may be okay with running security software in a secure environment. The performance requirements are not as high as in the case of the automotive.”

Conclusion
Mindset changes are happening. “Five years ago, it was not uncommon to find people building chips who thought they had no need for security,” says Borza. “That thinking has started to change. A lot of that is due to the attacks that we’ve seen in the wild. People are now being held responsible for the security of their systems, whether it’s through legislative means, or regulatory means, or in some cases through civil liabilities. Suitability for a particular task is one of the tests for things that are connected to the internet. The smallest, cheapest devices continue to be the ones that are the most problematic, and they’re problematic for everybody because those are the devices that may be present in large volumes on the internet, and they’re easily exploitable.”

The costs of cybersecurity are likely to continue to increase in the future. “One study says the cost of cybercrime worldwide will be $8 trillion in 2023, and another puts the 2025 cost at $10.5 trillion,” says Jolly. “There are technological efforts being made to improve cybersecurity, including more powerful encryption algorithms and hardware authentication methods like physical unclonable functions (PUFs). Furthermore, there is significant growth in cybersecurity education at the university level, and commercial cyber ranges are helping cybersecurity professionals sharpen their skills. New products will have to be designed with cybersecurity as a key consideration starting from the earliest architectural phases, and legacy SCADA systems will need to be hardened and retrofitted.”

The world is changing, and not always for the better. Security is not something anyone wants to think about, but criminals have found that the industry was lax and took advantage of it. The initial cost was borne by the users of semiconductors. Now those costs have become part of the semiconductor industry — power, performance, and area — and they will continue to increase to the point where it is no longer worthwhile for criminals to attack them.