Following up on the blog PKCS#11 with OP-TEE, this blog dives deeper with a hands-on example of using PKCS#11 on an NXP i.MX93 EVK running Yocto based Linux to securely connect/provision the device on the AWS IoT platform. While...
Background DM-Crypt is a disk encryption subsystem in the Linux kernel and can be used to protect sensitive data / intellectual property stored (IP) on external storage. For example, if an attacker copies the contents of the external storage media offline, they would...
Recently there was a hack published for Hyundai’s Linux based infotainment head unit. The device itself had implemented security features such as signed/authenticated and encrypted images. However the encryption key was stored in the Linux build system (Yocto) setup...
Manufacturing Internet of Things (IoT) devices involves installing sensitive material (e.g.: keys, certificates, IP etc.) on the device. Secure provisioning of these secrets requires processor/hardware support along with special tooling or software. Using NXP i.MX8...
Overview IoT devices incorporate keys / certificates for various use cases such as: authenticating to a cloud service, establishing secure network connections, securing Over-The-Air firmware update images etc. There are multiple software and hardware based solutions...
From customer expectations to cybersecurity regulations, the demand for security assurance of devices has never been greater. Yet device manufacturers find it challenging to secure Linux devices. Establishing a secure Linux platform requires deep expertise and time...
Overview The Yocto Project is a popular choice for creating custom Linux distributions for IoT devices. When creating a custom Linux distribution one of the key challenges faced by device manufacturers is the time and expertise required to secure the distribution....
The Security Content Automation Protocol (SCAP) is a method of using certain interoperable security standards to automate evaluating policy compliance of deployed systems. In order to scan a system for compliance or vulnerabilities, there are two components involved:...
A recent blog post by Kees Cook, a Linux security expert and Google security engineer, illustrates the challenges in maintaining the security of the Linux kernel. One of the main takeaways from the blog is: “If you’re not using the latest kernel, you don’t have the most recently added security defenses (including bug fixes).”
Going the “upstream first” route is the absolute best way of keeping the kernel secure. However, it is only part of the story.
Monitoring and managing vulnerabilities in embedded Linux devices presents a unique set of needs that traditional IT vulnerability tools fail to address and result in wasted efforts chasing false positives and inefficiencies due to cumbersome workflows. After evaluating multiple IT cybersecurity tools, we at Timesys ended up creating a vulnerability management tool called Vigiles, which is optimized for embedded devices. This blog aims to share the lessons learned and how the right tool can bring your security maintenance cost down while improving the security posture of the device.
With 300+ vulnerabilities being reported weekly in the US National Vulnerability Database (NVD), it is more challenging than ever to maintain the security of open source and third-party software used in embedded system products. One common approach to tackle the problem is to adopt a risk-based vulnerability management strategy in which vulnerabilities that pose the highest risk to your organization are remediated first. This blog outlines how to establish such an process as part of your software development lifecycle while keeping the maintenance cost and risk of exposure low.
Qualcomm Snapdragon processors support secure boot which ensures only authenticated software runs on the device. By configuring the processor for secure boot, unauthorized or modified code is prevented from being run. The authenticity of the image is verified by use digital signatures and certificate chain.
On Qualcomm processors the first piece of software that runs is called Primary BootLoader (PBL) and it resides in immutable read-only-memory (ROM) of the processor. By configuring the processor for secure boot, PBL can verify the authenticity of the Secondary BootLoader (SBL) before executing it.
Google Project Zero team discovered a method to read privileged memory from user space by utilizing CPU data cache timing to leak information out of mis-speculated execution. Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For more details refer to this blogpost.
This blog aims to introduce the concept of Trusted Execution Environment (TEE) and how end users can leverage open source software to safely deploy applications that require handling confidential information.
Secure boot ensures only authenticated software runs on the device and is achieved by verifying digital signatures of the software prior to executing that code. To achieve secure boot, processor/SoC support is required. In our experience, some of the more secure boot friendly processors with readily available documentation are NXP i.MX, Xilinx Zynq, and Atmel SAMA5 series. Some TI Sitara processors support secure boot, but might involve TI factory programming of signing keys and custom part numbers.
Embedded devices have unique security needs ranging from IP protection, anti-cloning / anti-counterfeit capability, device software integrity, user data protection, securing network communication, device authentication and ability to run only trusted applications. A wide range of open source technologies are available that can help implement the aforementioned security requirements. However, it is not always apparent which mechanisms are best suited for a given use case, resulting in a steep learning curve. This blog series aims at giving a high-level overview of the different methods to secure your product and help accelerate your trusted software deployment.
The Internet of Things (IoT) has quickly led to the deployment of ubiquitous, unattended devices throughout our homes, offices, factories and public spaces. In this continuously expanding connected world of devices and IoT, the need to update/upgrade your product’s software/firmware is a certainty. There is no single software update approach that fits all, but there are key questions you should consider when designing your approach. They are: Why, When, What and How.
Get our feed or signup to receive email notification of new blogs and updates.
