This article is based on a webinar by Markus Vomfelde, Director, IoT and Infrastructure Business Unit, Renesas Electronics Corporation. Markus has over 20 years of experience in the semiconductor industry. Working in different application areas throughout his career, security has always been one of his key competencies while supporting automotive and industrial customers. You can watch the full webinar here.
Data security is crucial for the protection of personal user data, as well as your IP and investment in product development. Malware and viruses, overproduction and device replacement, DDoS attacks, and copyright and IP infringement all present threats from which your company’s data must be protected.
In this article, we’ll discuss how to protect local stored data (data at rest), which typically consists of two main data types: the application program executed during operation (the IP of the manufacturer) and the local data used during operation (user data). After covering the basics of protecting on-device data, we’ll walk through planning a security implementation using a hypothetical fingerprint reader device as an example.
Protecting Locally-Stored Data: The Basics
Securing against physical access
The very first step is securing the device against physical access from external sources. This includes three main parts: locking programmer access so that code and stored data in the device cannot be read and malicious code cannot be injected, locking debugger access to both avoid code or data from being injected into the device or from analysis being performed on the device, and finally locking the flash memory to prevent erasure and reprogramming of the device (this prevents corruption of root keys and certificates and the corruption of critical code, such as the bootloader).
The second step is to isolate critical functions and data. Create a trusted environment by generating trusted or secure and non-trusted or non-secure parts within the MCU, and isolate the minimum critical functionality and data from any external access. It’s also important to minimize the attack surface by maintaining limited and defined entry points into the secure portion. Any API or other access to this data should be minimized as much as possible, but still, allow for thorough testing via these secure entry points. Hardware such as Memory Protection Units (MPUs) or the Arm TrustZone can be used for this type of isolation and access.
Securing on-device data with cryptography
In order to manage the secure part of the MCU, the use of cryptography is required. You must have a key, but one hidden from external access, so it should be encrypted to keep it secure. Additionally, there are typically three other main types of data which need to be secured and encrypted.
Your device may have portions of its software which need to be accessed to be copied, such as the application firmware which gives value to the product and needs to be protected. Additionally, during normal device operation, the user may store their keys in the device in order to access a network or identify a product in the system, and this as well as any other user-generated data will also need to be protected against unintended access.
These different data types in the device may require different kinds of encryption. Renesas devices offer numerous hardware functions to support different encryption types. For example, data which requires external access, such as a firmware update or network keys, should use asymmetric encryption to verify both the data source and data receiver, while data that is only locally stored in the device (such as user data) can be encrypted with hash functions to enable the application to access the data even without an external connection.
Planning Your Security Implementation
Deciding which data needs to be encrypted and in which way varies based on a number of factors. You must consider the manufacturer viewpoint, securing the value of the product, as well as the user viewpoint, protecting user data. There is also variability in the type of application; whereas an HMI interface might only need basic security, a device such as a key log would have much higher security requirements.
In order to make the right decisions on how to protect data at rest, you need to make a security implementation plan – considering factors such as whether the device is connected to the Internet and how it can be accessed, if the device is physically exposed to external access, and any other possible vulnerabilities or attack vectors. This plan requires an analysis of the full life cycle of the device, reasoning out the level of security required, and documenting this for future review and reuse in a broader security plan.
To demonstrate how to make a plan for protecting your data at-rest, we are going to walk through a security implementation using a fingerprint reader as an example.
Example: Fingerprint Reader
Imagine you have developed a new fingerprint reader to be used for door locks. It is to be used indoors to grant access to certain areas of a building. The fingerprints of frequent users are stored locally, as you have developed an efficient compression method to store the data in the device.
Infrequent users can get access via a Wi-Fi connection to an in-house server where all user fingerprints are stored, but this method takes a little longer. As you are continuously improving your software, you offer updates throughout the year, so the server must be connected to the Internet to receive the updates.
Seven Steps Towards Security Implementation
A security implementation can be broken down into the following seven steps:
- Step 1: Commit to designing with security in mind
- Step 2: Check applicable regulations
- Step 3: Define what you want to protect
- Step 4: Identify your vulnerabilities
- Step 5: Identify who you trust
- Step 6: Define your limitations
- Step 7: Make a plan
The first step is committing to design with security in mind from the very beginning. By reading this article, you are already doing so. Next, check any applicable regulations. Different regions and industries have different regulatory environments, so this is something you need to research for your particular situation.
What Do You Want to Protect?
The third step is to decide what you want to protect. This may include:
- Your investment in your product
- Your product’s operation
- Information stored in your product
- Information sent from or received by your product
- A service enabled by your product
There are many different sources which need to be protected in your device, but since we are talking about data at rest, the first three above are the most relevant to us. In our example of the fingerprint reader, we need to secure the IP of the fingerprint algorithm, which provides value to the product and must be defended against any access an attacker may gain to the device, whether directly or through a data connection. As the device is connected to a network, it is not enough to only protect the MCU; additionally, we must secure the IP from being dumped to the attacker from the memory.
Secondly, the user data, in our example the stored fingerprints and network access data, must be secured. While this is also in the hands of the user and the network security, proper security measures must also be implemented within the device itself.
Identify Your Vulnerabilities
Once we know what we need to protect, it’s time to identify our vulnerabilities. First, we must protect the IP value inside the device (in our example, the compression algorithm). We have to consider how this may be accessed, by whom, and when: during production, during operation in the field, and when the device will be replaced or operation is done.
Secondly, we must consider how to protect the user data in operation. Who can access this, how, and when? There is both the physical access to the key lock, as well as the network access to the device.
You must also identify whom to trust. For the sake of this article, we will assume you understand key provisioning and move on to the next step.
Define Your Limitations
The next step is to define your limitations. Making your device 100% secure can become very costly, and some security implementations may be overkill for your particular use case. For a device installed in an area without public access, security can be lower than for a device which is accessible to anyone. A device that is not connected to the Internet requires less security than one connected to the Internet, while a single-user device requires less than one with many users.
Important considerations are whether the device is connected to the Internet and how it can be accessed via the network, and whether user data can be reused on other devices or is only suitable for the single device. You must seek to strive for the right balance between the security implementation, the potential risk of an attack, and the kind of data which can be stolen or compromised.
Make a Plan
Finally, with the previous steps in mind, it’s time to make a plan for our security implementation. Let’s take a look at what this looks like using our example.
First, we look at the manufacturer’s concerns. The device key is the root of trust for the device and needs to have the highest security, but with a sense of proportion as it should be unique for the device and not reusable. The device key should be stored in an encrypted state, with no direct access by the MCU core.
Additionally, the firmware (in this case the compression algorithm of the fingerprint data) is the real value of the device, and must be protected against read out or duplication so that competitors cannot get access to the data and copy the implementation. This should also be stored in an encrypted state, with core access only via an API. This could be a time-critical implementation and requires care.
Secondly, we look at protecting the user side. The user will store the keys for the Wi-Fi connection to access the server, and this user key is critical data as it grants access to the user’s network and based on this, an attacker can gain further data from the company. This should be stored in an encrypted state, with core access via a security API. This is not time critical, as it’s mandatory only a few times a day.
Finally, we must secure the user data (in our example, the fingerprint data stored in the device). If this data is accessed, it will be useless to the attacker, as they don’t know the compression algorithm. The attacker can only reuse this data if he also has access to the compression algorithm, and even then he needs access to another lock. As this is unlikely, storing this data as plain data should be enough, but physical access must be disabled as described in the beginning of the article.
Protect your sensitive data with Renesas hardware
Renesas offers multiple MCUs that can help you realize your security implementation. To learn more, visit their website.
About the sponsor: Renesas
At Renesas we continuously strive to drive innovation with a comprehensive portfolio of microcontrollers, analog and power devices. Our mission is to develop a safer, healthier, greener, and smarter world by providing intelligence to our four focus growth segments: Automotive, Industrial, Infrastructure, and IoT that are all vital to our daily lives, meaning our products and solutions are embedded everywhere.