top logo netmoduleheader backgroundclaim netmdule: we speak embedded!

Protect your IP and your Reputation

Security for today’s embedded devices is getting more and more important.
In many cases a simple login screen with user management is simply not enough. By compromising an embedded device, an attacker may not only steal confidential information but he may endanger entire systems.

The security requirements of embedded systems are dependent on the application and may be different from other embedded or PC based systems. A threat/risk analysis and assessment defines the assets to be protected and the likelihood of threats compromising these assets. This is the decision base to define appropriate counter-measures.
In many cases security related counter measures can be categorized in one of the following categories.

Confidential Information
Most Embedded Systems need to store confidential information, typically user account information and VPN credentials.
The easiest approach to minimize the threat is to reduce the amount of confidential information on the device. For example not to store the plaintext password but only the passwords hash.
As alternative, Crypto Authentication chips can store confidential information in a non-retrievable way and still allow the use of the information in common authentication handshakes.

Communication Security
Communication security is a must for many Embedded Devices and we can distinguish between two categories. Human machine interfaces (HMI) where a person is accessing the device and machine to machine (M2M) communication.

For the HMI case, the PC based internet approach where the user authenticates the server based on a public certificate and the server authenticates the user based on passwords, smartcards, or other devices may be simply too expensive for industrial devices and a better solution is needed.

The M2M case adds additional challenges and advantages. The M2M communication is expected to always work without human interaction but in most cases we have a well-defined and testable set of communication peers. In other cases, for example alarming, communication is more important than security.
It is important to use the advantages of M2M communication to build a good, robust and secure communication framework.

Protection against Counterfeit Hardware
Product manufacturers often face two opposite requirements: cost effective (offshore) production versus the risk of counterfeiting. A flexible production supply chain based on several low cost partners adds the risk that a production partner may copy the device and sell it on its own.
One way to limit the risk of counterfeit hardware is to use cryptographic authentication devices. These devices are programmed at a trusted facility and shipped to the hardware manufacturer. The software - your asset - only runs on hardware equipped with such an authentication device. Devices that offer extension slots can be designed to only accept extension cards that have an authentication device with correct credentials.

Secure Boot / Secure Software Upgrade
“My system is secure because no one else can write software for my system”. Tempi passati.
Standardized CPUs and operating systems make it easier than ever for an attacker to write “malicious” software and upload it to an Embedded Device. In special cases entire open source projects focus on running “Linux” on devices. For example http://openwrt.org has precompiled images for a wide range of WLAN access points. If an attacker is able to execute his software on a targeted device, he may compromise many assets mentioned above.
One approach to prevent the execution of foreign/malicious software is Secure Boot. Most modern operating CPUs have features that allow to irreversibly locking a CPU to only boot signed code. Using this feature, developers can establish a Chain of Trust: 

  • The CPU only starts a signed Boot Loader 
  • The Boot Loader only starts a correctly signed OS
  • The OS then only starts correctly signed applications
  • The application only loads correctly signed configuration and only accepts correctly signed updates.

Depending on the threat scenario, the Trust of Chain does not need an anchor at CPU level. For example it may be sufficient to place the Boot Loader in ROM memory and start the Chain of Trust at Boot Loader level. While this approach sounds easy, careful consideration is needed. For example it is inefficient if a developer needs to sign the code prior to debugging. Giving each developer a signing key also increases the risk of exposing signing keys to the public (it is recommended to work with development keys). Secure Boot requires a solid design and a well-structured development process.

TrustZone
TrustZone is a security technology introduced by ARM Ltd. It provides hardware based separation of execution environments. TrustZone offers a secure execution environment. It provides hardware level protection that prevents code in the non-secure environment from accessing secure resources (GPIOs, RAM and flash regions and debug interfaces). It allows a clear separation of secure and non-secure functions.

Trusted Platform Module (TPM)
The trusted computing group defined the TPM standard (currently TPM 1.2). Implementations of the TPM standard offer security features for PCs and Embedded Devices:

Authentication: The TPM offers hardware assisted authentication algorithms. The TPM allows to store and seal keys. Sealed keys cannot be exported but can be uses by hardware assisted authentication algorithms.

Encryption: The TPM module allows to encrypt information using a unique hardware based key. Without the non-exportable key the information cannot be decrypted.

Platform Integrity: Together with the BIOS the TPM can be used to create a secure boot system.

Unified Extensible Firmware Interface (UEFI)
The UEFI is meant to replace the traditional BIOS used in many PCs. The UEFI 2.2 specification defines the secure boot. UEFI allows locking the hardware to only execute correctly signed OS images.



Stefan Leuenberger  Netmodule

Stefan Leuenberger

+41 31 985 25 10

Send E-Mail to Stefan Leuenberger