comment on this article

How to protect embedded software against attacks

An embedded system can be attacked by injecting malware at some point. Once installed, this can collect confidential data, change a system's behaviour or induce unpredictable actions.

These threats can be combatted using a properly secured boot process that allows only trusted software to run. To sustain a high level of trust, secure boot must rely on proven cryptographic algorithms. While this makes sense, a secure boot has its own challenges:
• The most appropriate algorithms are asymmetric, which requires intensive computing power
• The keys associated with these algorithms must be protected and their integrity retained
• The implementation must be flawless.

Authentication
To ensure the target runs only authorised software, firmware needs to be authenticated. This process – a digital signature – verifies that a piece of software is genuine and approved.

The software loaded during manufacturing must be signed digitally and this process should apply to each firmware update. A digital signature enables trust during the device's lifetime.

A strong digital signature must be computed by a public and well proven cryptographic algorithm. If system firmware is authenticated using an elliptic curve digital signature algorithm (ECDSA) and RSA, both combined with SHA, users can have a high level of trust.

Asymmetric cryptography
The fundamental principle of asymmetric cryptography is the software developer holds the private key, used for signing, while the embedded device stores the public key for verification. The importance of this cannot be overstated. The major advantage is that the confidential element – the private key – is never stored in the end product. Hence, if an ECDSA or RSA algorithm is used, an attacker cannot retrieve the private key, even with the most sophisticated invasive methods; all they can get is the public key and, by definition, it is impossible to retrieve the private key, even when the public key is known.

Fig 1 shows the process flow of a secure boot based on asymmetric cryptography. The ECDSA and RSA algorithms are supported by the SHA-256 hash algorithm, which provides the highest level of secure authentication. Why do we also need SHA-256? For performance reasons, it would be impractical to sign the full firmware digitally, so SHA-256 is used to compute a unique digest (a 'hash' value) which cannot be forged. This digest is then signed through ECDSA or RSA. These same processes are applicable to firmware updates. For those updates, software is downloaded, rather than programmed during manufacture, but the digital signature generation and verification processes remain the same.



Implementation challenges
While asymmetric cryptography offers essential benefits, it has a resource cost. Computing an SHA algorithm on a large piece of software is time consuming when done through software. RSA or ECDSA signature verification also requires overhead, especially if the main system MCU does not have a multiplier.

Another challenge is ensuring the integrity of the public key and its certificate. While a public key does not need to be kept confidential; it can be disclosed because it only allows verification, an attacker might want to substitute a different public key. If successful, the device would authorise fraudulent software signed by the attacker's private key. To avoid this, we must ensure the public key cannot be modified or replaced.

Many systems running on medium range MCUs cannot implement these basic requirements easily. Rather than changing the main system MCU, which might require a full redesign, a secure MCU can be added to implement a secure boot efficiently, handle the power and performance criteria and protect the public key, while guaranteeing a high level of security.

DeepCover MCU
With an integrated secure hash engine, the MAXQ1050 has the power to accelerate the computation of the firmware hash. This is important as hash time impacts the system's boot time directly. Because it has a modulo arithmetic accelerator, the MAXQ1050 can also perform fast ECDSA or RSA signature verification.

In the field use phase of a secure boot implementation (see fig 1), the MAXQ1050 will execute all steps and then inform the main system MCU and/or the power management IC (PMIC) of the authentication status. It can also provide application flexibility: for example, one of the MAXQ1050's GPIOs can enable the PMIC to power the main system MCU or one of its GPIOs could be connected to the main MCU's reset pin so reset happens only when firmware is verified. Optionally, the MCU's startup could be initiated by a specific sequence on the MAXQ1050's GPIOs.

The right security
It is often difficult to define the necessary level of system security. The highest possible level often results in high development and manufacturing costs. Hence, designers and users seek a trade off between cost and security.

Many issues affect these decisions. Will the attack be professional or amateurish? What will be the financial impact of a successful attack? Who might be hurt and how badly?

There are three potential levels of attack and the MAXQ1050 can respond to each level.
* Basic. The system is attacked using software, including malware. The attacker is unable, or not tooled to perform any physical attack or to modify any physical characteristic of the system.
In these cases, the MAXQ1050 implementation in fig 2 provides sufficient protection. NIST recommends key lengths greater than 2048bit for RSA and more than 224bit for ECDSA.
* Moderate. In addition to software, the hardware can be attacked physically by probing a PCB track to read a signal, forcing the level of a digital pin and/or removing an IC from the board.



While this level of threat is more complex, the standard MAXQ1050 implementation in fig 2 protects against some limited physical attacks, such as an attempt to replace the serial flash with a fake. The secure boot sequence using SHA-256 and ECDSA or RSA would detect any fake software.

To increase resistance to hardware attacks without increasing costs, additional layout precautions are recommended, including:
• Routing the tracks connecting the MAXQ1050 to the PMIC or main system MCU in the PCB's inner layers
• Using pulses or sequences of pulses to indicate successful boot. An attacker cannot connect the signal pins to a fixed level such as ground or VDD.
• Using at least two pins bearing different dynamic signals to inform the main controller that boot is successful. Route the tracks such that it would be difficult for the attacker to control both pins at the same time.

* High. Here invasive attacks, such as microprobing signals on the bonding wires of an IC, are used. Protecting against these sophisticated attacks requires an implementation that is compliant with FIPS 140-2 level 3 or 4.

Such implementations detect any physical tamper attempt and react immediately by destroying sensitive information and rendering the system inoperable. Since restoring device operation would require maintenance, this level of protection should be implemented only when security overrides availability.

Because the MAXQ1050 incorporates self destruct inputs and instantly erasable NVSRAM, it can support these requirements.

Christophe Tremlet is a marketing manager with Maxim Integrated.

Author
Christophe Tremlet

Related Downloads
59422\P21-22.pdf

Comment on this article


This material is protected by MA Business copyright See Terms and Conditions. One-off usage is permitted but bulk copying is not. For multiple copies contact the sales team.

What you think about this article:

Yes, I realise the MAXQ1050 is not a dongle in the physical sense; but instead a microcontroller to be soldered on the PCB; most likely on the same board as the main microcontroller. However it is still a dongle in its functionality - there is no difference in the operation of the device as far as software is concerned. Simply soldering the chip to the PCB on a bus of your choice is no different than exposing that bus to the outside world with a connector and fitting a dongle. If you have PHYSICAL access (to the PCB - i.e. your attacker is able to probe the PCB) then the attacker can reprogram the boot loader.

Of course, the very act of fitting a MAXQ1050 to your PCB means that you WILL need to change your boot loader and applications as described to enable your trust chain. Assuming that the boot loader (OS and middleware if applicable) and application code are written in a portable way (we all write portable code, don't we?), then there is little or no difference in the software work required to implement using a MAXQ1050 vs change to a host processor with integrated boot loader and security module. And, as you concede, the 'ideal secure boot is the one implemented within the main controller of a system ...'.

I agree for basic, non-invasive attacks, the MAXQ1050 may be a good solution for remedial actions.

For all other attacks, I am afraid I just don't agree. All of your security measures can be simply bypassed by replacing the boot loader code, thereby completely ignoring the MAXQ1050.
Indeed, it may be possible to reprogram the boot loader from within the system if the boot loader can be reprogramned without requiring external hardware (most firmware these days can be in circuit programmed by the host system)

So, to summarise using your security model:

- Basic: invasive attacks not considered, implementation as explained without further precautions
Providing the boot loader cannot be reprogrammed from within an operational system then, yes, I accept this is a valid option (although the software implementation and PCB re-spin may mean that you can achieve a higher security for the same cost)

- Moderate: invasive attacks considered to the point that an attacker could probe a PCB track. This level can be reached by using the precautions listed in the article
Disagree. Any point that the attacker has physical access to probe tracks then they will be able to replace the boot loader, completely bypassing the MAXQ1050

- High: designers must consider using the microcontroller self-destruct inputs and designing PCB meshes and/or secure envelope
Disagree. Any point that the attacker has physical access to probe tracks then they will be able to replace the boot loader completely bypassing the MAXQ1050.


Posted by: Andy Simpkins, 20/02/2014
It is true that the ideal secure boot is the one implemented within the main controller of a system. This is, for example, what we offer at Maxim with products such as the MAX32590 which supports a full secure boot for a platform including a Linux operating system if desired. The MAXQ1852 also does support this for simpler applications. So, each time a designer wishes to implement a secure boot, he can change a main microcontroller with one of those.

That said, changing the main microcontroller for a secure one often has a major impact on the hardware and software design. Not everybody can afford this change. So this article is about implementing secure boot for applications where it is not possible to change the main micro. The MAXQ1050 is not a dongle but a microcontroller to be soldered on the PCB most likely on the same board as the main microcontroller.

Now, rather than 'is it secure?, the question should be 'to what extent is it secure?'. We all know that absolute security does not exist. All protections can be defeated, given the right amount of expertise, money and time. So the target level of security should be thoroughly defined before any implementation happens. As mentioned in the article, MAXQ1050 is flexible to allow three levels of security:
- Basic: invasive attacks not considered, implementation as explained without further precautions
- Moderate: invasive attacks considered to the point that an attacker could probe a PCB track. This level can be reached by using the precautions listed in the article
- High: designers must consider using the microcontroller self-destruct inputs and designing PCB meshes and/or secure envelope

The latest level would, for sure, demand higher investment and is only applicable for applications requiring the highest level of security. That said, it allows compliance with FIPS 140-2 level 3 and 4. This level is considered as very high as this is the one for military or financial applications. The MAXQ1050 with its self-destruct inputs enables this security level. Several of our customers have designed such products with our technology and have passed the certification.


Posted by: Christophe Tremlet, 20/02/2014
A nice paper right up to the point that you suggested that a device external to the main system controller is capable of providing security...

No no and thrice no.
Dongles have been shown to be breakable in the PC world, and were abandoned years ago why do you think they are applicable now in the embedded world?


Given physical access (your moderate level), the attack vector is not the dongle (in this case the MAXQ1050), bypass this complacently with a replacement boot loader.

The only way to achieve a secure boot is to have authentication right the way down. that means that the initial boot mechanism must be monolithic inside the main MCU, the first stage boot loader must be mask programmed (or OTP), and it must contain the public key(s), and any self destruct anti-tamper.

You can not just bolt a security module onto an existing platform, it must be designed in, to suggest that a 'dongle' is capable of achieving the same is flawed.


Posted by: Andy Simpkins, 14/02/2014

Add your comments

Name
 
Email
 
Comments
 

Your comments/feedback may be edited prior to publishing. Not all entries will be published.
Please view our Terms and Conditions before leaving a comment.

Related Articles