Vertical Summary - OEM Security
The goal of this article is to provide a framework of device security from the device manufacturer’s standpoint. That is the target is the OEM making an embedded device that is either placed into other devices by machine manufacturers or is placed directly into end customer use.
Original Equipment Manufacturer (OEM) device security leverages tactics and practices to ensure that products are protected against potential threats and vulnerabilities throughout their lifecycle. Devices and software communicating inside and across multiple industries is increasing at an exponential rate. Connected devices in automotive, healthcare, and consumer electronics, need robust security tactics and practices to maintain user safety, data integrity, and regulatory compliance.
Tactics for OEM Device Security
Establish a Security Framework: Adopting development frameworks like FDA FD&C Act, UL 2900, IEC 62443, MITRE ATT&CK, or the IoT Security Foundation Framework allows companies to assess and react to security measures in Design, Manufacturing, Supply Chain, Field Operation, and Field Decommissioning:
These frameworks are essential as Ebert & Beck stated in IEEE Software vol. 40, no. 6, 2023: “One third of companies have no established product cybersecurity program or dedicated R&D security team.”
Use a Hardware Root of Trust (RoT): It is important to protect the private cryptographic keys and the cryptographic operations using those keys. This avoids an intruder from learning about the key and provides a secure means to encrypt, verify identities, and prove a devices identity. Hardware devices like a Trusted Platform Module (TPM), Secure Element (SE), Trusted Execution Environment (TEE), or specialized hardware areas (like CAAM) are important to creating a hardware based Root of Trust on the device. This provides a high degree of trust in the authenticity of the device performing communications
Enable Secure Boot: As the device starts up, the device’s firmware is checked to make sure it is authentic and has not been modified from the OEMs authorized image. This helps prevent malicious code from being loaded during boot and creating potential attack vectors in systems. The process makes use of firmware signing and the delivery of signing keys to the device during manufacturing.
Sign Firmware: In addition to signing firmware for use during the secure boot process, firmware should be signed when it is delivered to the device via an update (typically over-the-air or OTA). Before implementing the firmware update, the firmware signature needs to be validated and checked against a chain of trust provided by X.509 certificates coming from a trusted PKI. The signing operation should be behind a robust set of policies and procedures to prevent any nefarious internal actors from gaining access to production signing keys. Following these methods (signing and verification) prevents malicious code from being loaded onto the system.
Encrypt Communications: The use of the latest TLS algorithms and versions in mutual authentication mode (mTLS) provides mutual trust between the device and other devices or the device and other systems. These protocols prevent eavesdropping and encrypt the data passed between devices. Combining mTLS with a Hardware Root of Trust allows all encrypted communication to happen in a place that is difficult to compromise. This ensures the authenticity, confidentiality, and integrity of data exchanged between devices and other systems.
Secure Sensitive Data: Ensure that sensitive information (personal, security related, or the like) is encrypted when at rest. Combining this encryption with a Hardware Root of Trust to protect the encryption/decryption mechanisms is important.
Implement Access Control: Implement robust access control mechanisms to restrict unauthorized users or services from accessing sensitive parts of the device. This includes secure user authentication and role-based access control (RBAC). For SSH sessions to devices, consider using SSH Certificates for user authentication. The use of SSH Certificates prevents managing and sharing keys on devices and between users. Eliminate the use of usernames and passwords for shell access.
Support Patch Management: Establish processes for delivering and applying security updates. Devices should support over-the-air (OTA) updates to quickly patch vulnerabilities as they are discovered. Some fields, like Medical devices, also require processes to communicate these vulnerabilities to any affected entity.
Use Logging and Monitoring: Create policies to log critical events like firmware signing, firmware updates, security breaches, configuration changes, certificate/key rotation, SBOM creation, and other critical functions. Create policies that require regular auditing of these logs for nefarious events. Purpose-built software can speed the integration into signing, certificate generation, and SBOM generation into these policies and procedures.
Use a Zero Trust Architecture: In OEM devices consisting of multiple subsystems, consider a Zero Trust Architecture. This strategy Zero Trust assumes that subsystems (like power supplies and memory sub-modules) may be compromised. Therefore these subsystems need to authenticate each other and verify trust with every communication. This is increasingly important in devices deployed in hostile or untrusted environments, and can leverage X.509 certificates from a trusted PKI.
Consider Physical Security: Since many OEM devices are deployed in remote or unmonitored locations, physical tampering is a major threat. Items like potting
Best Practices for Securing OEM Devices
Security by Design: Integrate security at every stage of the product development lifecycle, from initial design, to the supply chain, to the Firmware Development Lifecycle, through to manufacturing, deployment, and device decommissioning. Make sure to have these security policies and procedures documented and regularly audited to assure compliance.
Threat Modeling: Policies and procedures should include threat modeling. There are several models that can be utilized. Some of these are:
STRIDE: (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) classifies threats these categories. It looks at systems (hardware, firmware, and network interfaces) and analyzes by each category.
DREAD: (Damage potential, Reproducibility, Exploitability, Affected users, Discoverability) helps prioritize threats based on their potential impact. It is similar to the FMEA process used in failure analysis.
Attack Trees: visualize threats hierarchically from the attacker’s goals down to the possible ways to achieve those goals. Attack trees are effective in OEM device environments because they allow detailed exploration of specific attack paths targeting hardware, software, and supply chain vulnerabilities.
Supply Chain Threat Modeling: OEM devices often depend on third-party components, making the supply chain a critical risk vector. Supply chain threat modeling involves assessing risks from suppliers, manufacturing processes, and distribution networks. It evaluates the trustworthiness of vendors and identifies potential vulnerabilities in component sourcing, firmware signing, and hardware integrity.
Contract Manufacturing: OEM devices are often produced at factories owned by others. This contract manufacturing location may not be trusted. Evaluating these threats is important to securing the supply chain.
Vulnerability Management: Establish a process for identifying, disclosing, and addressing vulnerabilities in the device post-release.
Regulatory Compliance: Adhere to relevant industry standards and regulations, such as the EU Cyber Resilience Act (CRA), to ensure your devices meet security and auditability requirements.
Keyfactor’s OEM Ecosystem
Initial Device Certificate: Identify a device as coming from a valid manufacturer. Additionally, this can be used to assure that any firmware upgrade is made on OEM hardware. Some implemented use cases include:
Lifetime Certificate (examples: IEEE 802.1AR - IDevID, Matter DAC)
Birthing Certificate: To onboard an operational certificate
Validate the device as valid before applying a firmware upgrade
Securely perform certificate signing operations inside of untrusted contract manufacturing facilities
Signing Solutions: This is a way to prove that an authorized organization has created a document at a specific date and time, and that the document has not changed. For OEM devices, typical use cases include:
Signing OTA packages - the package sent from the cloud to the OTA agent on the device is signed to prove authenticity & non-tampering.
Secure Boot (Linux) - the Linux kernel and/or modules are signed. This makes the Linux kernel and modules immutable from what the OEM manufacturer loaded. NOTE: This is different from Device secure booting.
Secure Boot (Device) - The entire boot chain is signed and loaded. That is, the immutable ROM bootloader verifies the integrity of the first stage bootloader (FSBL). The Root of Trust is typically embedded via fuses in the hardware for this FSBL. The first stage bootloader initializes hardware peripherals and verifies the integrity of the second stage boot loader (SSBL). The SSBL is used to initialize more hardware and verifies the integrity of the operating system or kernel.
Operational Certificates: OEM Device manufacturers that are also operators can leverage Keyfactor’s operational certificate management. This includes items like birthing certificate to operational certificate rotation, operational certificate rotation and management, centralized device trust store management, IoT Hub integrations (digital twin creation automation), automated device vetting, and automated cryptography updating.