4 Q＆As about Security for Embedded Systems That Might Interest Embedded Developers

PublishTime： 2020-11-14 Article Source：Silicon Labs

Hosted by Jeff Shepard, EE World has organized this “virtual roundtable” into “Security for embedded systems” Panelists include Haydn Povey (HP), General Manager Embedded Security Solutions with IAR Systems, Mike Dow (MD), Senior Product Manager, IoT Security with Silicon Labs, Jim McElroy (JM), VP of sales and marketing at LDRA Technology, and Dave Hughes (DH), founder and CEO of HCC Embedded.

Q1. What is the most challenging learning curve for embedded developers when first starting to implement security features?

Haydn Povey (HP), General Manager Embedded Security Solutions with IAR Systems

HP: The most challenging aspect of implementing security is to understand what you are protecting, who you are protecting it from, and the value of the asset or impact an attack may induce. These are very difficult questions for any organization to answer, especially the potential impact, as there are relatively few reference points. For example, the need to protect Operational Technology (OT) against malware was seen as a relatively low priority for organizations until the recent spate of attacks, many of which have had an impact of tens of millions of dollars. The way to step over this learning curve is to adopt a standard, such as the EN 606345 for Consumer Electronics or the IEC 62443 for industrial and smart city applications. These standards outline the basic requirements for security, such as ensuring no fixed passwords and the move to proper cryptographic identity; the need to disclose vulnerabilities which requires proper versions management and code signature; and the need to enable updates into every device, with a formal secure boot process enabling a solid foundation that the device can trust whilst remediating. There are many other requirements, such as secured communications, but these become substantially easier to implement once the device has solid secure foundations.

Mike Dow, (MD) Senior Product Manager, IoT Security with Silicon Labs

MD: Typically, the most challenging aspect for developers new to security is gaining a good understanding of security basics. Security is like any other technology; you must understand the technology fundamentals before you can implement it. I think many engineers get hung up on the math of cryptography, and it spooks them. If they can start thinking as a system engineer and visualize the algorithms as a black box with function with inputs and outputs, it simplifies the process and makes the basic concepts easier to grasp. The truth is that if you don’t know the difference between asymmetric and symmetric cryptography – or what a hash function is good for – you will be overwhelmed and less likely to implement security at all or poorly if you do.

JM: For embedded software developers, the most challenging learning curve may center on understanding the scope of where security needs to be considered secure hardware, secure communication protocols, secure operating systems, secure boot, encryption, secure data at rest and in transit, secure coding practices to eliminate security vulnerabilities, robustness testing, etc. The list of considerations is large, and often the cost of developing a robust and secure embedded system becomes a major consideration. Decisions get made based on the anticipated “risk” of the system being exploited.

DH: All embedded development is challenging. Security requirements add to the challenge, and the degree of that challenge is determined by the target system’s specific security requirements. The jumping-off point is a detailed assessment of the risks from which you build, mitigating each risk while always keeping in mind that complexity obfuscates.

Q2: What is the simplest thing designers can do to enhance embedded systems and devices’ security?

DH: Designers need to create a proper assessment of the risks their device should defend itself against. This is the core of building any security case and ensuring the resulting design is focused on what is actually required by the product without introducing unnecessary complexity. Reduce your attack surface!

JM: The simplest thing designers can do is apply automated static analysis, leveraging the latest secure coding standards like MISRA and CERT. This helps ensure secure coding practices and eliminate security vulnerabilities. For embedded software, best practices recognize that security needs to be considered from the beginning. It’s neither cost-effective nor functionally effective to bolt on security after the system has been built. Secure coding practices need to be applied, checked, and standardized across an organization. The simplest and most cost-effective way to accomplish this is by automating standards compliance, which also significantly enhances the embedded system’s overall security.

Jim McElroy (JM), VP of sales and marketing at LDRA Technology

MD: Lock the debug port before you ship the product. It sounds simple, but you would be amazed how many times that is not done. The next most basic task is to have a secure boot based on an immutable root of trust. A secure boot is one of the most effective tools against all kinds of attack vectors.

HP: The simplest thing designers can do is to use the right tools. There are many nuances and challenges in the implementation of security, and no one expects every engineer to become a cryptography expert. Using the right tools can transition security from a complex engineering challenge to something every organization can implement. Similarly, there is a need to engage with the designers’ CISO team. Aspects such as product identity, vulnerability disclosure, and patching methodologies are all technologies the CISO works with every day on their IT systems, but by bringing the right skills set into the products, we can ensure the right balance of security and usability.

Q3: In general, how well are embedded device security maintenance and updating implemented?

JM: Most embedded devices, once fielded, are left alone, or at best “patched” when security vulnerabilities are identified. Once a vulnerability is discovered. However, it’s often just too late. Valuable information may have already been taken, or the system infiltrated with malware waiting for the right time to operate maliciously. Updates to these systems may require either physically connecting the system to a network or opening the device up to over-the-air (OTA) updates. This patching—which again may occur too late—requires secure communications.

MD: Typically, not well, unfortunately. Doing an over-the-air update securely is not trivial; you need a secure boot loader and lots of example code and documentation. It is important when selecting a vendor that you grill them on what enablement they have around this function.

HP: Traditionally, many update and maintenance schemes are not great. Many do not protect the code with proper signatures, enabling malware to be deployed, and many operate at a high level in the application space, whereas there is a clear need to presume almost every aspect of the system can be compromised. In fact, the first principle of updating should be every device can be compromised, and hence every device requires a safe-haven to recover and remediate from. In our solutions, we focus on the automatic creation of a robust Secure Boot Manager, which does all of the bare-metal work to ensure the device boots into a clear and secure space, where it can then check for a properly formatted, signed, and encrypted update. This multistage approach presumes that there will be many versions of software over the lifetime of a product, and hence, versioning and anti-rollback must also be integrated.

DH: I do not think there is a general answer to such a question since every device has different risks associated with it. You must make the assessment based on the goals of the particular device. If data is not a security risk, why protect it? Companies that do a proper risk assessment and then build mitigation based on the assessment will have a high level of confidence in their solution. Those that do not cannot make any meaningful claim.

Dave Hughes (DH), founder and CEO of HCC Embedded

Q4: Do most embedded designers understand the importance of secure boot configurations and how and when to use secure boot to enhance embedded systems security?

MD: Secure boot in a microprocessor running Linux has been well understood and used extensively for the last five years or so. For a microcontroller with embedded flash, it is still a very new concept and one that not a lot of engineers have undertaken. The new IoT requirements from ETSI and NIST include authentication of code before runtime, which is forcing the conversation now in a microcontroller (MCU).

DH: Most embedded developers do not actually have anything to do with secure boot configurations. If the system designers’ risk assessment mandates secure boot, then specialists implement this.

JM: Knowledge of the importance of secure boot is more prevalent in the industries where the risk of devices being exploited is higher (e.g., avionics system, autonomous vehicle control systems, medical infusion pumps). These systems require the highest security and safety assurance levels since the life and safety of the device operator, passengers, or patient can be adversely affected by improper operation of the device. Secure boot configuration is often overlooked in loosely connected or standalone devices.

HP: Most embedded developers understand that secure boot managers are important; however, even with technologies like Arm TF-M, there is a need to build and support security systems for the long term. There is a global shortage of 3.5 Million cybersecurity experts, and so it is no surprise that these skills are in demand, and few engineers have the breadth of knowledge to understand what they are protecting, who they are protecting it from, and how best to implement the solution. The reality is the EN 303645 specification demands that all consumer embedded systems have a secure boot framework, and the IEC 62443 industrial IOT does the same in the industrial domain. There are practically no connected devices that do not require a robust, Secure Boot Manager.

+1 Like
Add to Favorites

Recommend

Technical Resources

More>

New Products & Solutions

More>

This document is provided by Sekorm Platform for VIP exclusive service. The copyright is owned by Sekorm. Without authorization, any medias, websites or individual are not allowed to reprint. When authorizing the reprint, the link of www.sekorm.com must be indicated.

Integrated Circuits