Top 3 Firmware Verification Use Cases with Secure Elements (Part 1)

In today’s marketplace, embedded electronic systems are immensely varied and subject to more and more certifications like the IEC62443 security standard for industrial applications or sometimes regulations depend on the critical nature of their operations. Yet security is more than regulations, it’s about implementing fundamental and responsible practices and today we are discussing firmware verification for small and constrained embedded systems. Each embedded system operates based on the code it executes (firmware, software, RTL etc.…). In part one of this series, we will look at what could happen to that connected pacemaker, industrial gateway, IoT baby monitor or even a motor in an industrial machine if their firmware is attacked. Keep an eye out for part two, where we will discuss how to implement those use cases on various embedded systems.

The code of a product is where a lot of company’s intellectual property (IP) resides. The code of the connected pacemaker, controls human life and becomes extremely critical. That same pacemaker is also subject to certifications. In the industrial pump, the code is what makes the motor perform better because it handles the speed and torque regulation better than competition. The industrial gateway code is architected to handle very large payloads in a complex smart factory network at the best speed in the market but behind that gateway is an industrial network with machines and operators. Now, this quickly becomes a safety concern for individuals in the factories if the machine operation were to be altered. The IoT baby monitor code ensures a robust connection with the network but also provides parents with relevant and private information about their newborn. Below, we’ve shared four reasons why a company’s code is so precious to their IP. A company should consider the threat model as defined in various existing standards mentioned here:

1. Remote digital attack: Is the exploit accessing the code remotely to impact the target or the entire fleet of products?
2. Remote logical attack: Is the exploit focusing on a bug in the code that can help the hacker to scale an attack remotely across the network?
3. Local physical attack: What can be done to the code, not necessarily by exploiting a bug if the hacker has physical access to the product?
4. Local logical attack: What can be exploited in a code bug if the hacker has physical access to the product?

To address the concerns above, in the recent years, governments and industries have started to shape IoT security regulations to create standards. For example, in the industrial market, the ISA/IEC62443 standard documents security practices to design an industrial product. The EN303656 driven from Europe follows the European government’s security regulation and guidance to sell an IoT product in the local consumer market. UL2900 which started with a heavy focus on software security practices is now being looked at by major companies for the consumer market. Within all the main standards or regulations, you will find common requirements recommending verifying that your code is genuine.  

 So, what can be done to protect this code and what are the trade-offs?

The code will need to be verified with cryptographic operations to make sure it is genuine. The verification can be performed at various points in time during the embedded system operations. 

When to verify the authentic nature of a code?

1. At boot: the common technical term is secure boot, which has various ways to be implemented either using symmetric keys or asymmetric keys, either verifying only a digest, signature, or an entire code image. The secure boot process is intended to ensure only genuine code executes on the target embedded design. 
2. During runtime: a more generic term here is IP protection. Firmware engineers may decide to implement a code verification at any relevant point during the system operation, aside from secure boot and Over-The-Air (OTA) updates, to make sure it has not been tampered with. 
3. After an OTA update: in the world of IoT, once a new code image is pushed, “over-the-air” via a network to replace the existing one, this new code must be verified as genuine before it runs. 

The three embedded security functions described above relate overall to code verification practices. 

Now, let’s look at implementation techniques and then we’ll review their tradeoffs. Fundamentally, the code will need to be “signed” in your corporate environment, which is ideally secure, and then “verified” inside the embedded system. Those “sign” and “verify” operations are performed by cryptographic algorithms and sets of symmetric or asymmetric keys. There are four major steps as shown below in the diagram. The first one is to look at what’s happening during manufacturing and how the code encryption and signing is handled. The second is how the code is loaded into the embedded system (secure loader). The third step deals with how the code is downloaded into the embedded system. The fourth step focuses on what’s happening inside the embedded system after it’s manufactured to ensure the code running on the target application is indeed genuine. 

Signing Operations during Manufacturing with Symmetric Keys

Symmetric cryptography is based on a shared key architecture, in other words a pair of two keys that will be identical (symmetric keys or also called shared keys). The major downside is if someone accesses one key, the other shared key is identical, and the system is easily defeated. In addition, a fundamental practice would require having a different symmetric key for each device which creates a logistic paradox: how unique symmetric keys can be provisioned into entire fleets of devices. As a consequence, exposure to those keys becomes worse as developers use the same symmetric key for entire fleets of devices due to ease of implementation and project schedule constraints. But let’s take a look at it. The first step happens within your company environment.

• Your code, as Original End Manufacturer (OEM), would be passed through a “hash” function. We are using SHA256 as an example here. The output of this hash is a 32-byte digest of the code image.
• That hash is performed using a symmetric key (Signing OEM key). 
• The output is a “MAC” or message authentication code.
• The MAC is provided to the contract manufacturer (CM) who will flash the main controller at the production site. Both the MAC and the symmetric key are loaded by the CM at this stage. 
• Note this is where supply chain vulnerabilities happen as the keys should never be exposed and certainly not during manufacturing nor within the microcontroller. This moment in time is where keys are exposed to the operators inside your factories and the equipment that would perform the MAC if not done by the OEM already.

Figure 1: Symmetric signing at OEM site

Signing Operations during Manufacturing with Asymmetric Keys

A more robust and scalable method consists of leveraging asymmetric keys instead of symmetric keys. Asymmetric keys are a key pair where the two keys are different, but mathematically related by a cryptographic algorithm. For the example, we will use an ECC-P256, one of the most commonly and efficient used algorithm for embedded systems. The private key will sign the code, the public key (calculated from the private key) will verify the signature and/or digest.

Figure 2: Asymmetric code signing at OEM site

Ask Yourself, Who Has Access to Your Keys during Your Manufacturing?

No matter if you chose a symmetric or asymmetric architecture, there are a few important questions to ask yourself. As you will need to load the cryptographic key inside your embedded system to verify the image, ask yourself:

• Can you trust your contract manufacturer with the key that protects your signed code? Remember your code is your company IP. If they have the key, they can access your code. 
• Does your CM have access to the signing key or the key used for verification? What happens to your keys when you want to change one or multiple contract manufacturers? 
• Are you dependent on your contract manufacturer because they possess the keys?
• How do you manage various sets of keys pairs if you hire multiple contract manufacturers?
• How are the keys protected at the contract manufacturer? What would a security audit outcome be?

There are also a lot of supply chain questions to consider when it comes down to the logistics of handling keys in manufacturing. The signing key is always the most critical key to isolate from everything and everyone possible, ideally using an HSM. But now you are in a situation where the verification for your code becomes a very high-value target as it controls how well you protect your code (remember it’s your company’s IP). The keys are now in the hands of your contract manufacturers which is when your vulnerability exposure grows. There are a few questions you might want to ask yourself including:

• Do you know if your keys are securely stored or shared among employees?
• Are your keys remotely accessible from outside of the factory due to poor manufacturing equipment network protection?
• Is it possible for your employees to simply use a USB stick to exit the factory containing the verification key and how is that audited and trusted?
• What happens to the keys if the employee in charge of them leaves their job at the contract manufacturer?

Where Are Your Keys in Your Embedded System?

Think twice if you have the public key verifying your firmware inside a traditional microcontroller flash. The cryptographic would then be part of the binary image of the code. A traditional engineer would simply load the keys (public or symmetric) in the flash of a microcontroller or processor. Let’s talk about the questions you should ask yourself and the answers you should think through.

How Valuable Is This Key and What Can an Attacker Do with It?

As of today, there is still a vast fleet of devices that store keys in the clear of the flash memory. Some of the basic strategies for the attacker is to try to access the memory of your device using various techniques such a buffer overflow (example: Heartbleed), HEX file extraction, or other methods to get access to the keys located in the memory. Those are very real attacks, and several companies are reporting such vulnerabilities in their systems. At this point, all bets are off to start mounting a scalable attack. If every key is accessible as they are in the binary image, they become changeable, reproducible and remote access to a large fleet becomes more and more possible. If we remember from earlier in this article, using symmetric keys is not the most robust strategy for code signing. Let’s now assume the key that will verify the code is inside an OTP within the controller. The OTP approach is a logical first step to make your system is a little more robust because now the key is located in an immutable memory zone. Immutable doesn’t mean inaccessible or unreadable, it just means not changeable. Depending on how much value or IP is in your code, the value of your code is how much you should value your key. So, if your key is accessible, it can be read, copied and reused. Now any rogue user can legitimately use that key to get their own code verified. 

• If it’s a symmetric key, that would be the worst-case scenario, especially if the system is cloud connected. When the key is accessed, the attacker can now perform a MAC of their rogue code, and have it verified with a checkMAC easily because signing the symmetric key is the same as the symmetric key that will verify the code. Even worse, if key diversification has not been used, it is extremely important to think through the list of people who have the keys for your entire fleet of devices. All of your baby monitors connected industrial machines can be counterfeited, all your OTA update could be corrupted, and the scenario could get worse. 
• If it’s a public key in the controller flash or even an OTP that is accessed, the rogue user can now copy the key and reuse it at will to legitimize user authorization and later on install rogue code and run it on the target microcontroller. 

Using a public key infrastructure versus a symmetric key architecture is much more robust as the private key signing the code is different yet mathematically related to the public verifying the code. That said, having access to the public key allows the attacker to see and trigger the verification of the code but also the decryption before it’s executed. At that point, the question becomes, “Now that I see the code, what if I change the code and bypass the verification by the public key?” The BootROM capability inside the microcontroller or processor in addition to the proper cryptographic accelerators such as ECC-P256 from a Microchip secure element are needed to address this problem. The BootROM will ensure the memory zone where the controller issues the verify command is also immutable and cannot be bypassed. Yet having access to the public key still remains an essential problem.

What Are the Advantages and Disadvantages of Using Symmetric vs Asymmetric Keys for Firmware Verification?

In this part 1, we have discussed in detail the importance of implementing firmware verification in applications. Your application code will need to be verified with cryptographic operations to make sure it is genuine. The verification can be performed at various points in time during the embedded system operations such as at boot, during runtime and during a secure firmware upgrade. There are a number of techniques to implement the firmware verification using asymmetric and symmetric cryptographic algorithms. Each of these techniques have their own advantages and tradeoffs. In part 2 of this blog article series, we will discuss how to implement firmware verification using Microchip’s secure elements and microcontrollers.