Login   |   1.866.392.4897 |   sales@timesys.com English Japanese German French Korean Chinese (Simplified) Chinese (Traditional)

PKCS#11 with OP-TEE: Securing IoT device keys


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 to securely store and use these keys / certificates. PKCS#11 is a standard that has been around since 1995 and widely used in the Enterprise Server / PC world to provide a standardized way for applications to use keys / certificates in a platform independent manner. Support for PKCS#11 in IoT device software has been growing over the years to achieve a similar level of security and standardization.


What is PKCS#11?

PKCS#11 is a standard specifying an application programming interface (API) for:

  • Management (creation, modification, deletion) of cryptographic objects such as:
    • Keys (RSA, Symmetric keys, Elliptic Curve Cryptography etc.)
    • Certificates (X.509)
  • Using the cryptographic objects to perform operations such as:
    • Encryption and decryption
    • Signature generation and verification

Why use PKCS#11?

PKCS#11 provides applications a platform independent manner of using keys securely AND can also be configured to ensure the keys are never exposed to the application, hence vastly reducing the attack surface. For example, applications can request signing or encrypting data without ever needing to know the private keys.


PKCS#11 system view

A system supporting PKCS#11 typically comprises of these elements:

  • PKCS#11 provider, the backend implementing the crypto store for the objects and supporting the necessary algorithms/operations specified by the API. 
  • PKCS#11 utilities for loading, configuring and managing the PKCS#11 provider libraries.
  • Application support for using PKCS#11 interface.

Figure illustrating PKCS#11 based system

Figure illustrating PKCS#11 based system


PKCS#11 provider

Dedicated security processors

These are dedicated security IC’s typically connected to the main processor via I2C or SPI or USB interface. They support various cryptographic algorithms and have built-in non-volatile memory to store keys, certificates, etc. Many of them are also FIPS or Common Criteria certified and compliant to industry standards such as IEC 62443. They come with middleware software (e.g.: cryptoauthlib) that typically support PKCS#11. Popular security chips incorporated in IoT devices are:

  • Trusted Platform Module (TPM): SLB9670, ST33.
  • Hardware Security Module (HSM) / Secure Elements: NXP EdgeLock SE050, Microchip ATECC608, Silicon Labs Secure Vault, STSAFE-A110, USB based: NitroKey, YubiKey

Some considerations when using dedicated security processors are:

  • Added cost to hardware
  • Possibility of vulnerabilities in its firmware and/or hardware requiring replacing or re-flashing
  • Quality of vendor software support may vary, possibly un-audited proprietary software

Software solutions (Backed by SoC hardware Root of Trust)

Software based solutions such as firmware TPM (fTPM) and softHSM can emulate TPM/HSM functionality and be used in conjunction with PKCS#11 libraries. However unless these software is run on a hardware isolated portion of the processor such as Trusted Execution Environment (TEE) or Secure Enclave they do not add much value from a security perspective. Hence the preferred software solution would be to run a “Trusted Application (TA)” emulating HSM functionality running on a TEE.


PKCS#11 Application support

PKCS#11 has been long supported in popular open source software that employ security (e.g.: OpenSSH, OpenSSL, OpenVPN, httpd, wpa_supplicant etc.). Furthermore, leading IoT kits (e.g: AWS GreenGrass, Azure IoT etc.) support PKCS#11 to authenticate devices and securely connect to cloud services. Similarly Over-the-air (OTA) firmware update clients such as swupdate, aktualizr, RAUC, mender all support PKCS#11 to varying degrees.


Key management in IoT devices

IoT devices are typically “userless” devices and keys/certificates are the main mechanisms to authenticate devices and secure data / network connections. With PKCS#11 support, the providers can act as key stores supporting crypto operations that the PKCS#11 enabled applications can make use of in a secure fashion.

Examples of various keys used on IoT devices include: firmware update keys / certificates, device identity keys / certificates, disk encryption keys, WPA keys, web server keys and certificates, cloud and device to device communication keys, application keys for encrypting data (PII, logs, database, configs etc.).. all of which can be secured and managed using PKCS#11.

Without PKCS (Azure IoT client: direct access to private key)

identity_pk = "file:///var/secrets/device-id.key.pem"

Note: Typically without PKCS#11 support, the key is secured with a combination of full disk encryption (dm-crypt) and discretionary access control to the file, providing a minimal baseline security.

With PKCS (PKCS#11 URI i.e. reference to crypto object):

pkcs11_lib_path = "/usr/lib/libckteec.so.0"
identity_pk = "pkcs11:slot-id=0;object=device id?pin-value=1234"


OP-TEE as a PKCS#11 provider

IoT devices using ARM processors can leverage the combination of TrustZone hardware technology in conjunction with an open source Secure OS (e.g.: OP-TEE) to achieve the functionality provided by HSM/Secure Elements.

The OP-TEE OS can run “trusted apps” and one such app included is a PKCS#11 TA which acts as a PKCS#11 provider (i.e. implements HSM with PKCS#11 support in software). Using the PKCS#11 TA, various device secrets / certificates illustrated in the previous section can be securely provisioned within OP-TEE at manufacturing time. Cryptographic operations such as signing or encryption can be performed without the private key being made available outside of OP-TEE. Thus on embedded Linux based devices, a secure keystore with PKCS#11 support can be easily achieved with OP-TEE. 

Example usage of PKCS#11 TA with OP-TEE

Example usage of PKCS#11 TA with OP-TEE


The user space applications running on Linux can directly use the PKCS#11 interface via cryptoki client library (libckteec) included with OP-TEE client or via other libraries/clients (e.g.: openssl engine, pkcs11-tool/OpenSC, p11-kit). The PKCS#11 libraries and tools are readily available in both Yocto and Buildroot. Access to the crypto objects and operations can be restricted by:

  • Standard default PKCS#11 PIN based authentication (Security Officer/SO and user PIN)
  • Linux ACL based authentication

Note: A prerequisite to securely using OP-TEE (+ PKCS#11 TA) is:

  • OP-TEE OS/TA is authenticated as part of Secure boot and chain of trust
  • OP-TEE OS is setup to use SoC supported Hardware Unique Key (e.g.: NXP i.MX CAAM) for secure storage


PKCS#11 specification does not require all cryptographic mechanisms to be supported. Some PKCS#11 providers might only support a subset of mechanisms (e.g.: AES ECB might be supported but not AES CBC). If an application has a stringent requirement on the use of a certain PKCS#11 mechanism, then it is prudent to review the mechanisms implemented by the provider. Similarly applications support might largely vary and it is prudent to review the same.


Provisioning devices with keys / secrets needs to be done securely at the manufacturing facility after the device first boots. So appropriate mechanisms and infrastructure needs to be in place.



Leveraging OP-TEE as a PKCS#11 provider adds an additional layer of security to your IoT devices and eliminates the need for a dedicated security chip.

Timesys offers a PSA certified security solution – VigiShield which includes OP-TEE based PKCS#11 support leveraging hardware root of trust. Schedule a free security consultation with us to learn more.

IoT security simplified with PSA Certified VigiShield

IoT security simplified with PSA Certified VigiShield

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 investment; right from selecting the processor with the necessary security features, researching and configuring the myriad of open source software modules, and having the necessary mechanisms to regularly maintain security of the device through its life. Besides securing the system software, the device manufacturers need to worry about application security and keeping end customer data confidential. Hence the road to security is a long and expensive journey.

One of the best ways to reduce the cost of security development, improve security posture and bring secure devices to market faster is by leveraging off the shelf pre-certified components. PSA certified provides a framework for security assessment and certification of processors, system software (e.g: Linux OS, RTOS) and devices evaluated by independent labs. Device manufacturers can leverage PSA Certified components (processor and system software) to quickly start with a secure platform and focus on their value add software. Optionally they can submit their devices for certification as well to give the end consumer a peace of mind. PSA certified components also align with meeting industry security standards such as NISTIR 8259A and ETSI EN 303.


Image credit: PSA Certified


Timesys has developed VigiShield Secure By Design, a PSA certified system software which device manufacturers can leverage to bring secure Linux devices to market faster. VigiShield is available in the form of a Yocto layer and is highly configurable to support custom hardware/BSP or any custom security needs. Out of the box, it includes security features such as software integrity (secure boot and chain of trust), secure storage, secure over-the-air (OTA) updates, linux kernel and system hardening, secure communication, locked hardware ports, security audit logs and more. Additionally Timesys supports manufacturing tooling required for secure software provisioning. The security layer leverages the best in class open source solutions to bring easily maintainable security feature implementation to your Yocto based Linux distro.

The other major challenge device manufacturers face is the long term security maintenance of their Linux devices. With more than 350+ new vulnerabilities reported each week, it is a daunting task to monitor their applicability to the open source components used in devices and issue security updates. Timesys Linux OS/BSP Maintenance subscription service provides long-term security updates and maintenance of your Linux OS. Using this service device manufacturers can rely on timely security updates that can be deployed to devices in the field with the secure and robust OTA update mechanism included in VigiShield. 

With security built-in, device manufacturers can focus more on innovation during the product development process and get to market faster. Schedule a VigiShield consultation today.



VigiShield Secure By Design for Yocto

VigiShield Secure By Design for Yocto


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. Having helped multiple device manufacturers through this journey, Timesys now offers a standard product called “VigiShield Secure by Design.”  This is available as a yocto layer (meta-vigishield) that delivers out-of-the box security to your Yocto-based Linux distribution. VigiShield implements the OS security features covering various security standards such as NISTIR 8259A, ETSI EN 303 and has obtained a PSA Level 1 certification through an independent security lab evaluation. By leveraging VigiShield, device manufacturers can now focus on their value-added applications instead of worrying about security.


Security Features Implemented by VigiShield


Secure boot and chain of trust

A key aspect of security is ensuring only authentic software runs on the device (i.e. malicious software is prevented from running). To achieve this, each piece of software is digitally signed at the time of building the software and the signature is verified on the device before executing that piece of software. If the signature check fails, the software is not allowed to run. The authentication of the first piece of user software i.e. bootloader is referred to as “Secure boot” and extending the authentication to all other software including user space applications is referred to as “Chain of Trust.”
Note: To achieve secure boot, there is a dependency on the hardware needing to support it.

VigiShield supports secure boot and chain of trust on various hardware platforms. Taking the NXP i.MX8 processor series as an example, VigiShield integrates and configures the code signing tools provided by NXP to create signed bootloader images as part of the build. All pieces of software that are loaded after the bootloader are signed and verified using open source technologies. For example, the kernel, device tree and initramfs (optional) are all bundled in as a signed fitImage and verified by the bootloader. Similarly a signed read-only root filesystem is authenticated using the Linux kernel dm-verity mechanism.

Resources: Secure boot and chain of trust blog, Faster secure boot blog. Webinar


Secure Storage

Secure storage ensures data confidentiality (e.g: keeps customer/application data private), prevents IP-theft, and prevents cloning/counterfeiting of the device. Data is secured by means of encryption and the encryption key is typically protected by a hardware specific mechanism.

VigiShield provides full disk encryption using the Linux dm-crypt mechanism and the encryption key is kept confidential by a hardware/processor root of trust (hardware unique key). For example, the VigiShield implementation on the i.MX8 processors achieves this by creating an encrypted blob which is protected by a unique master key residing in the one-time programmable fuses of the processor. Only authorized software can request that the processor perform decryption through the hardware cryptography engine.

VigiShield also supports a secure keystore to protect device keys and certificates. The keystore leverages OP-TEE as a PKCS#11 provider adding an additional layer of security to your IoT devices and eliminates the need for a dedicated security chip.

Resources: PKCS#11 with OP-TEE blogEncrypted Data storage blog


Secure updates

Software/firmware updates are required in order to provide security or feature updates to devices. Secure Updates ensures that only authentic and legitimate firmware is  updated on the device.

VigiShield provides a secure and robust over-the-air (OTA) solution. This includes OTA server authentication using certificates, secure downloads over TLS1.3, installation of signed / authenticated images using Public-key cryptography (PKCS #1.5 signature validation, using 2048 bits RSA key with SHA256) and prevention of unauthorized rollback (anti-rollback) of images. Apart from authenticating the firmware update bundle, the individual images (e.g: bootloader, kernel etc.) are authenticated as part of secure boot as described in the previous section.

VigiShield uses the SWUpdate open source solution for OTA updates with an A/B update scheme. However, through our VigiShield professional services team, we can customize OTA updates to use other solutions such as OS-Tree, Mender and RAUC; all with the same set of security features.

Resources: Designing OTA Updates webinar


Secure communication

Secure communication protects the data-in-transit when the device communicates with external devices (e.g: cloud servers, remote sensors, etc). Secure communication is achieved using authentication between all involved parties and encrypting the data transmitted between them.

VigiShield secures external communication to/from the device by using secure protocols such as TLS1.3, which are implemented as part of open source libraries such as openSSL. The certificates/keys used to authenticate any external communication are stored in the encrypted and authenticated secure storage, to avoid any potential tampering. VigiShield further reduces the attack surface by disabling many known weak/insecure ciphers in openSSL.


Security audit logs

Security audit logs record any runtime security violations/breaches on the target system. Security events such as unauthorized access to sensitive files, opening of network connections, failed login etc. are typically logged to an access controlled, integrity protected log file for further investigation.

VigiShield supports logging security violations on the target system using the Linux audit framework and open source auditd user space utility. The log file access is restricted to root users and any unauthorized access to the logs are also recorded. VigiShield comes with baseline logging capability and can be customized to monitor specific security events based on end user requirements.

Resources: Logging with auditd blog


Secured ports

Incorporating hardware security is critical to mitigate physical attacks on the device. VigiShield can be easily configured to disable and/or password protect interfaces such as serial port and JTAG.



Security hardening is the act of reducing the attack surface of the device and making the device more difficult to hack. VigiShield implements a variety of system hardening techniques.

  • Toolchain hardening: The toolchain used to build the target device binaries has security flags to make exploiting vulnerabilities difficult. VigiShield enables toolchain options such as stack protection, buffer overflow checks, position independent executables etc. 
  • Kernel hardening: The Linux kernel hardening is a broad topic since there are a myriad of security features, hardening options, and mitigations for known exploits that can be enabled via the Linux kernel configuration. VigiShield provides a detailed kernel hardening report of the recommended hardening options based on your hardware architecture and kernel version; along with a base set of options pre-enabled.
    Resources: Kernel hardening blog, webinar
  • U-boot hardening: VigiShield can help mitigate a wide range of threats such as tampering u-boot environment variables, overriding boot commands, access of serial console, etc.
    Resources: Securing U-Boot blog
  • Userspace hardening: If software such as dropbear/openssh are included on the target device, VigiShield hardens the software by disabling root access, enforces key based authentication instead of passwords, etc.
  • Best practice cryptography: VigiShield disables a wide range of legacy / insecure OpenSSL ciphers by default.
  • Access control: Vigishield is configured to have no root login or default hardcoded passwords. As part of VigiShield, a discretionary access control report is generated detailing the permissions of each file in the filesystem. For example, details on the actions that users and groups can perform on a file: read, write, execute.
    Resources: Discretionary Access Control blog


SBOM and vulnerability report

Software Bill of Materials (SBOM) is an essential component for performing vulnerability or license analysis, both of which play an important role in software supply chain risk management.

VigiShield includes SBOM generation (SPDX), vulnerability (CVE) monitoring and management as part of Timesys Vigiles free tier offering.

Resources: Vigiles SBOM and vulnerability management


VigiShield Add-ons

Yocto/BSP and Security Customizations
Apart from the standard PSA certified VigiShield offering, we provide customizations as part of our Professional Services which covers hardware enablement, Yocto customizations, custom security feature implementations, integration with device management / IoT cloud services, and more!

Security Training
Whether you are new to security, looking for consultation to refine your security requirements or help integrating our solutions into your processes; we can help with our customized security training offerings.

Secure manufacturing assistance
We have expertise in developing the manufacturing tooling required for secure software programming and provisioning. We can help integrate your custom or 3rd party solutions for securely storing device certificates.

Trusted Applications for Secure OS
For customers seeking enhanced security, we have expertise in implementing “trusted applications” that can be deployed on a secure OS (e.g: OP-TEE, Trusty, etc) running on a trusted execution environment.
Resources: Trusted Software with OP-TEE blog, webinar

Long Term Linux OS security and maintenance
Timesys Linux OS/BSP Maintenance subscription service provides long-term security updates and maintenance of your Linux OS. Using this service, device manufacturers can rely on timely security updates that can be deployed to devices in the field with the secure and robust OTA update mechanism included in VigiShield.



The DIY route of securing a Yocto-based distribution is a tedious process and adversely affects the time-to-market for device manufacturers. Worse yet, without the right expertise and independent 3rd-party evaluation, devices might still be at risk. By leveraging off-the-shelf, security certified products such as VigiShield, device manufacturers can now bring more secure devices to the market faster and at a lower cost. To learn more, schedule a free security consultation.

Yocto Security: Automating compliance using OpenSCAP

Yocto Security: Automating compliance using OpenSCAP

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:

  • SCAP content, typically consists of a list of rules to audit
  • SCAP scanning tool that can interpret the SCAP content to perform the check on the system and optionally remediate

To illustrate using a practical example, a security requirement can mandate not storing any plain text passwords in a file. This requirement can be encoded as a rule using one of the specifications under SCAP, for example Open Vulnerability and Assessment Language (OVAL). Then to perform a scan of the system to assess compliance, a SCAP compatible tool such as OpenSCAP scanner can be used to read the SCAP content (e.g. OVAL file) and report the assessment in a standardized format.

The SCAP content is generally developed by software vendors and/or device manufacturers, sometimes in conjunction with authorities such as Center for Internet Security (CIS), Defense Information Systems Agency (DISA), National Institute of Standards and Technology (NIST) etc. There is a publicly available repository of pre-existing compliance checks and profiles based on industry standards such as PCI-DSS, HIPAA, DISA STIG, NIST SP 800-53 etc. This can be used as a baseline and any additional security requirements can be layered on top of the existing checks and/or profiles. While there are a lot of guides available on how to leverage SCAP on commercial / open source Linux distributions, the information regarding usage with custom Linux distributions is sparse. The next section is intended as a getting started guide for SCAP on embedded / IoT Linux devices using Yocto project as an example.

Getting started with OpenSCAP on Yocto

Yocto has a meta-security-compliance layer under meta-security that packages both SCAP scanner (OpenSCAP) and SCAP content (SCAP Security Guide). Using these packages a security audit of the target device (QEMU in this case) can be performed. 

To begin, follow the setup instructions on the OE-Core wiki page. Note: If you are using Poky or any other reference distro, there are some variables that need to be tweaked which will be covered later in this article.

Step 1: Get source code

git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://git.yoctoproject.org/meta-security
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake oe-core/bitbake

Step 2: Build setup

source ./oe-core/oe-init-build-env
//Add the below lines to bblayers.conf
BBLAYERS += "${TOPDIR}/../meta-openembedded/meta-oe"
BBLAYERS += "${TOPDIR}/../meta-openembedded/meta-python"
BBLAYERS += "${TOPDIR}/../meta-security/meta-security-compliance"
//Add the below line to local.conf
IMAGE_INSTALL:append = " os-release openembedded-release oe-scap scap-security-guide "
bitbake core-image-minimal

SCAP for configuration checks

The scap-security-guide package includes a basic security profile which can be used to audit the system. This is a very minimal security rule set and is to be used for illustrative purposes only. Follow the below instructions to run the scan with the basic profile. 

Step 3: Run openscap scanner

//Start a qemu instance of the built image
//Run oscap on the qemu target console
# oscap xccdf eval --report basic-embedded.html --profile xccdf_org.ssgproject.content_profile_basic-embedded /usr/share/xml/scap/ssg/content/ssg-openembedded-ds.xml
Title   Verify All Account Password Hashes are Shadowed
Rule    xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed
Result  pass
Title   Limit the Number of Concurrent Login Sessions Allowed Per User
Rule    xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions
Result  notapplicable

Interpreting the report

The tool generates reports in multiple formats including a human friendly html file which can be viewed directly on the device or copied over to a host PC for viewing. Below is a screenshot of the sample report and if you want to play around with the actual report visit this link. 

The summary section gives a big picture view of the compliance results along with the severity of any failed checks. The rules overview section lets you filter based on the result status and search for specific rules. The other nice part is to filter based on a profile group, for example if you are trying to achieve a particular compliance e.g. HIPAA, you can pick that group and the results will be rearranged to automatically map the rules to the relevant section of the security standard. 

The “Result Details” section provides detailed information on each rule along with any applicable references to various compliance requirements mapping. The results section also provides details on what exactly was checked for and/or if a check was skipped.


SCAP for vulnerabilities assessment

Apart from using SCAP for configuration compliance checks, OpenSCAP can also be used to check if the software installed on the system is patched for known vulnerabilities (typically CVEs). Distributions such as Ubuntu provide an OVAL feed containing data about patched versions of software which can be used to audit the system. In case of “build your own distro” such as Yocto, BuildRoot, OpenWRT the team responsible for creating the distro would have to create such a feed. It is a cumbersome process and hence not widely used. However if one wishes to create such a feed, for Yocto users, the oe-scap package in the meta-security-compliance layer provides a reference example. Below is an illustration where the oscap tool is used to check if CVE-2017-7502 is patched in the nss package on the system. This can be further automated using the openscap daemon which can run on a periodic schedule.

# oscap xccdf eval /usr/share/oe-scap/OpenEmbedded_nodistro_0.xccdf.xml
Title   CPE-2017:1365: nss security and bug fix update (Important)
Rule    oval-com.redhat.rhsa-def-20171365
Ident   CVE-2017-7502
Result  pass

Customizing SCAP content

A good starting point for creating custom SCAP content is by leveraging the work already done by the community. The Compliance As Code project has pre-existing rules/checks/profiles available for Linux systems and a “new product” guide for creating custom content. The project already has profiles that map to various security standards that can be inherited for the new product being created as illustrated in this patch. Another place to look for public SCAP content is the NIST National Checklist Program.


Debugging failures

A commonly faced issue when running oscap is checks return as “notapplicable”. The most likely reason for this is because of a VERSION_ID mismatch. The default expected VERSION_ID is nodistro.0 as specified in the /etc/os-release file. The best way to debug such scenarios is to pass in the “–verbose DEVEL” argument when calling an oscap application on the target device. Depending on your Yocto version you might need this patch for correctly mapping the VERSION_ID. 

# cat /etc/os-release 
PRETTY_NAME="OpenEmbedded nodistro.0"

 The SCAP content can link multiple different specs within each other, hence it is useful to understand the linkage/dependencies. To inspect SCAP content, use the oscap info command and then trace the linked checklists/checks/dictionaries for any possible errors. The below example inspects a SCAP source data stream (DS) which encapsulates links to rule checklists (XCCDF), compliance check definitions (OVAL) and dictionaries to identify software (CPE).

# oscap info /usr/share/xml/scap/ssg/content/ssg-openembedded-ds-1.3.xml
Document type: Source Data Stream
Imported: 2018-03-09T12:34:56
Stream: scap_org.open-scap_datastream_from_xccdf_ssg-openembedded-xccdf-1.2.xml
Generated: (null)
Version: 1.3
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-xccdf-1.2.xml
		Status: draft
		Generated: 2019-07-06
		Resolved: true
	           Title: Basic Profile for Embedded Systems
			Id: xccdf_org.ssgproject.content_profile_basic-embedded
		Referenced check files:
			system: http://oval.mitre.org/XMLSchema/oval-definitions-5
			system: http://scap.nist.gov/schema/ocil/2
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-oval.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-ocil.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-cpe-oval.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-cpe-dictionary.xml


Whether you are looking to embrace security automation or trying to meet regulatory compliance requirements, SCAP can play an important part of your security toolbox. Leveraging the OpenSCAP project, one can get a jumpstart in building secure devices that can be easily audited in an automated fashion. 

Learn more about Timesys security solutions for out of the box hardened OS profiles and vulnerability monitoring to automate your DevSecOps and meet compliance.

Akshay Bhat is CTO, Embedded Products and Services at Timesys. He oversees the strategic direction of Timesys’ technology roadmap. With more than 16 years of industry experience with embedded systems software development and security, Akshay’s focus is on Timesys solutions that transform the software development lifecycle for embedded and enable the development of embedded system products with stronger security. Akshay has authored numerous embedded Linux and industry articles and delivered several embedded systems security presentations. He received his MS in Electrical Engineering from NYU Polytechnic University.
The many challenges of Linux OS / BSP security maintenance

The many challenges of Linux OS / BSP security maintenance

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



The “upstream first” strategy is only half of the story for embedded devices

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. The challenges faced by device manufacturers running on Linux on embedded devices is vastly different.


Evaluating vulnerability tools for embedded Linux devices

Evaluating vulnerability tools for embedded Linux devices

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



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.


Vulnerability management and triaging

Vulnerability management and triaging

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



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.


Secure boot on Snapdragon 410

Secure boot on Snapdragon 410

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.

Secure Boot process overview

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. (more…)

Meltdown and Spectre vulnerabilities

Meltdown and Spectre vulnerabilities

Updated on 8/14/2018

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.

So far, there are three known variants of the issue:

Variants 1 & 2 are referred to as Spectre and Variant 3 as Meltdown.

Timesys has been monitoring vendor websites and open source mailing lists regarding affected CPUs and software mitigation strategies, and below are our findings: