Computer viruses, phishing attacks, and other web-based nuisances can wreak havoc online. What is more subtle — and perhaps less appreciated — is that we’re often surrounded by connected, embedded devices that were considered science fiction just a few short years ago. Tiny wireless-enabled chips are so inexpensive that they are commonly employed in simple physical devices like light bulbs, thermostats, and doorbells to add desired new features like power savings and control.
With this ever-present network of connected things, consider the ways a malicious actor could use an unsecured fleet of devices for nefarious purposes. Taking control of your network, potentially gathering personal and financial information, or possibly forming part of a botnet.
Ideally end users will set up their devices securely, but engineers and system designers should not assume this will be the case. Device security must be integrated into a product from the start. This is especially important in a world where hackers can access new techniques, artificial intelligence (AI) and other advanced tools, potentially creating new attack vectors or enhancing existing cyber security hacks.
In this article we will examine five critical concepts to assist in implementing OEM device security.
#1 Security is a continuous journey that spans the entire product lifecycle
When a connected device ships to a customer, it is presumed that engineers have been diligent to ensure its security. While an individual engineering team may be focused on security, what about the next person or team that takes over a project? How can a large and complex organization ensure that security practices are uniformly adopted and implemented across all relevant teams? Additionally, how should security threats be addressed that emerge later in the product life cycle?
These concerns are addressed in the Microsoft Security Development Lifecycle guide. Microsoft outlines the following five tenets of security that are essential to ensuring best design practices company wide.
- Requirements – Define the task at hand and the inherent security requirements
- Design – Design software/firmware to meet said security requirements
- Implementation – Write code according to design specifications
- Verification – Analyze code for errors and security flaws
- Release – Release updates incrementally so any immediate flaws can be quickly rectified
Microsoft is best known for its software, cloud offerings and services. However, in our age of increasingly intelligent connected devices, the same concepts can be applied and adapted to OEM product security. In tandem with these core tenets, continual training is necessary to ensure human capital stays up to date and that countermeasures identified earlier are implemented.
Finally, while a manufacturer may not be directly involved in the disposal of hardware at the end of a product lifecycle, consideration should be made for what happens to an OEM device after decommissioning. Documentation that instructs the end-user to properly destroy sensitive data is a good start, but this may or may not actually happen. Having mechanisms in place to expunge sensitive information when it is no longer process critical is even better.
#2 Two-way secure authentication
In a perfect IoT world there would be no need for security, and data could simply be transferred from one device to another. Unfortunately, malicious actors are continuously seeking ways to compromise networks large or small. Security breaches come in many shapes and sizes. Whether it is found on the embedded device, on individual computers or even in the cloud, not having two-way authentication is a top reason for security breaches.
Embedded devices are often overlooked in the security and authentication picture. One of the best ways to combat this threat is for OEMs to build secure authentication capabilities directly onto the device. Security-integrated designs are easier with secure elements from leading silicon providers.
Device Authentication involves securely identifying devices in connected environments and allowing network access only to authorized and uncompromised devices. Device identity management can implement solutions such as public key infrastructure (PKI) based digital certificates. These certificates establish trust and counteract exploits like identity spoofing and IP address forgery. PKI is a digital passport that can recognize authorized devices, users and services in public and private systems and allows you to encrypt and sign data.
Connected devices often live in non-secure environments. This can cause challenges in both industrial and consumer applications. Illegitimate gateways and end nodes can steal data or even send false data. Knockoffs or clones that are not built with quality and security in mind can cause failures that hurt OEM’s reputations and interrupt legitimate revenue streams for consumables. Hackers can install malware that can extract keys, data and firmware and rogue apps that can take systems or their associated data offline in denial-of-service ransom attacks. All these reasons and threats make authentication critical. Authentication using hardware-based cryptography, protected keys and digital signatures can enable the authentication needed in an efficient way.
Some hardware solutions help to provide additional security through a physically unclonable function (PUF.) The PUF takes slight differences that are in every single chip created and uses them to create a unique but repeatable signature or cryptographic key for each individual semiconductor. This key can be removed once it is used, so that it is not there to be stolen. It is important for OEMs to authenticate their devices and data to make sure the device is approved and not a clone and that the data is coming from a known and trusted
#3 What does secure boot do?
One way hackers have tried to attack IoT and other deployed devices is through firmware attacks. Secure boot ensures the firmware is legitimate and is from the manufacturer before running it on a device deployed in the field. This process is done using a combination of private and public keys.
At the manufacturer, the processor is burned with hashed root keys that are generated from a certificate in a one-time programming process. The private key is kept securely by the manufacturer. The public key cannot be changed once initially programmed, meaning it cannot be modified by malicious code. Because the public key is mathematically paired to the private key, it can reside safely on deployed devices. At boot, the operating system checks the signature and the keys to verify that no tampering with the code has occurred.
To add additional security, the secure boot code is stored on the device, typically in a one-time programmable location (OTP) that gets locked down so it cannot be altered.
While secure boot can enhance security, it comes with caveats. First, while the OS may be from a known source, this does not mean that other software/firmware running on a system is secure or free of vulnerabilities. It is also entirely possible that vulnerabilities may eventually be found in the verified OS itself. This can require field updates. Secondly, if the private key is lost, the device in the field can no longer receive firmware updates to keep the device up to date. If the private key is compromised, the security chain of the device can also be compromised.
With secure boot implemented, a device boots using only firmware intended for the application and has been signed and trusted by the manufacturer.
#4 Secure OTA: Why is it important to have this feature?
Over the air updates (OTA), are used to keep wireless devices current. These devices vary in complexity from connected light bulbs to automobiles, medical equipment to HVAC (Heat, Ventilation, Air Condition) systems, and even critical infrastructure for cities.
The ability to perform updates over the air is crucial. Consider a connected light bulb, turning lighting on and off may not seem like an immediate threat, but the thought of what could a hacker do once they breached your network is more concerning. If one bulb can be compromised, it could be possible to escalate privileges on this “simple” device, eventually compromising the entire network. On a larger scale let’s consider an application with a more safety critical application. If the wrong firmware is installed on an automobile, there is a clear and immediate danger to its occupants. Like the connected light bulb, it is entirely possible for issues to propagate to a wide range of other systems.
Ultimately the question is whether a particular product should have OTA capabilities. Especially when considering something as safety critical as an automobile. In a perfect world, where software, firmware, and mechanical systems are secure, safe, and dependable when coming off the assembly line— one could make an argument for physical updates only. However, in today’s world of evolving systems and nascent autonomous driving, updates are a necessary complication. Not to mention, consumers and professionals want the convenience and real-time nature of OTA updates.
Unfortunately, devices in the field can be compromised by hackers and have critical bugs that need to be fixed. Firmware updates are necessary to keep devices secure and fully functional throughout their life cycle. As all products become more software dependent, OTA updates will need to be available, dependable, and secure. Using proper encryption techniques, once the firmware reaches the device the secure boot process can verify the firmware update during boot-up to confirm that it is legitimate.
#5 Device-level security vs cloud-level security
While the world has moved to a cloud-based infrastructure for many computing functions, we still need physical devices with storage and local computing power. This can take the form of a smartphone, an industrial control system, or an internal network of monitoring devices that historically might not even been consider as a legitimate target on a closed network, but today there is more access. Securing physical devices, the data, and IP they contain requires a certain amount of effort. While pushing computing resources to the cloud may eliminate some headaches, it adds pressure to secure your data and that of your customers in transit and at rest.
Well-known procedures such as multifactor authentication, strong passwords, locking devices when not in use and keeping them in secure locations where they cannot be physically stolen are obvious security strategies. For devices deployed at the edge or the gateways they are connected to, personal information data, company data, and other IP should be protected with proper encryption, passwords alone are no longer adequate.
It is also important to secure memory. In some cases, a secure enclave or trust zone within the silicon devices in the embedded systems should be used. Using silicon from suppliers that design parts with security in mind is key. Edge devices can be much more efficient, secure, and robust if designers select electronics with security features such as hardware-based crypto accelerators and random number generators used in security algorithms.
Additionally, ensuring correct configuration, proper storage practices, and even discarding unnecessary data can help to mitigate risk. With industrial controls systems, one might even create a secure link between interface elements and put policies in place where infrastructure details are not shared with groups, internal or external, for whom access is not necessary.
Techniques like SSL (Secure Socket Layer) historically or its successor TLS (Transport Layer Security), use public and private keys to protect data in transit from local devices to the cloud ensuring transferred information is properly secured. Any encrypted data that is intercepted will be unrecognizable to anyone without the key.
Ensuring sensitive information is not sent or received without encryption is critical. Precautions must be taken by both sender and receiver to avoid security breaches by an attacker impersonating an authentic device. In cloud security, it can be tempting to assume that system safeguarding is the responsibility of the cloud provider. While a cloud provider should have robust security, and they provide the tools needed for secure data transmission, configuration of these security features is essential to avoid breaches. Manufacturers and users must ensure their cloud configurations are secure as unlike local assets, cloud assets inherently need to be accessible from the internet and are open to more threat vectors. When communication is done securely, the authenticity of the device and cloud can be assured by knowing the server’s certificate has the private key that is a match to the public key in the certificate of the end device.
Consider what data gets stored locally and what needs to be stored on the cloud, as well as what needs to be encrypted or deleted. Cloud assets must be inventoried to ensure that this storage does not become an ever-expanding repository of unused and potentially sensitive data. Unlike local storage that requires physical infrastructure to operate, more cloud storage and computing power is a matter of payment.
Whether or not data is local or in the cloud, you are ultimately responsible for your information and that of your customers. Take advantage of your cloud provider’s security features. These features are designed to secure your fleet of devices and prompt quick action in case of a breach, enabling you to shut down an edge device or compromised gateway, or issue a new OTA update to be deployed at scale. Regular checkups on your cloud providers’ security practices, what they store for you, and how things are configured help to alleviate risk.
OEM Security is Paramount
As an OEM, your customers need assurance that you have done everything you can to prevent security breaches, and that you are poised to respond quickly — and with minimal damage — if a breach does occur. Help form that trust by observing the practices and ideas found here, along with others appropriate for your industry. Finally, keep your security procedures up to date with continuous diligence to stay ahead of potential attackers.
To learn more about security solutions, download the Arrow embedded security solutions eBook today.