Identity and access management (IAM) systems in typical enterprise IT environments rely on a chain of trust that is rooted in human identities: For example, a personal ID, our social security number, and other official documents that are based on our birth certificate registered and stamped by a public authority. PKI systems are a way to replicate a similar chain of trust for machine identities – for connected devices that are mass-produced in factories and receive a digital birth certificate that is registered and signed by a trusted certificate authority.
Use cases for IoT ecosystems cover the whole triad of confidentiality, integrity, and availability:
- Tamper-resistant device identities (also called machine identities or IDevIDs, e.g., to prove the device is genuine, preventing counterfeiting)
- Strong device authentication to authorities, directories and other network or cloud services, as well as between devices. Because IoT assets in the field are not protected by common enterprise IT security controls such as perimeter firewalls, they are more vulnerable to attack, such as control server spoofing or man-in-the-middle (MITM) attacks. IoT devices that have been compromised can be exploited to extract data from servers or gain access to other systems.
- Access control of users, devices and services incl. APIs
- Confidentiality and privacy, e.g., by encrypting data at rest and in transit from/to IoT devices, such as process parameter streams or medical data
- Code signing for provisioning, secure boot and firmware/software patches
- Data integrity (think medical devices, or condition monitoring of high-power/high-impact actuators like valves in a pipeline or drone motors)
- Monitoring of devices for abnormal behaviour and, if necessary, revoking privileges,
- Harden devices against attacks such as manipulation, denial of service botnets or ransomware in general, and lay the groundwork for a zero-trust architecture
CyberCompare has guided several IoT manufacturers through the process of specifying PKI systems, comparing offers, and selecting PKI vendors (or vendor combinations). Here are a few things to consider before making a decision.
Is a PKI required or recommended for all (I)IoT devices?
While attacks on IoT devices are on the rise, the answer is clearly no – e.g., for sensors that do not process data and that will not receive any software updates during their lifetime, a static credential may be sufficient in most cases. Cameras with systems on chip, PLCs, electronic control units for vehicle components, power supplies or medical devices are all typical examples of IoT devices that are typically protected by PKI systems. A systematic risk and threat analysis should always serve as the foundation for decision making. As a general rule, the higher the devices are in the Purdue model, the more likely a PKI system is the best solution for establishing identity and access management.
Can both public or private PKI infrastructures be used for (I)IoT device identity management?
Manufacturers of IoT devices must obtain an authority certificate (typically X.509 standard) in some way, either by purchasing from publicly trusted root certificate authority (CA), or by issuing from private CA. Both are feasible, with distinct advantages and disadvantages (managing private root CAs is much more effort, of course, but common for IoT applications). Before connecting devices the certificates are registered centrally (for example, in one of the cloud hyperscalers’ IoT platforms) ) and signed into a chain of trust.
What are typical (I)IoT device constraints that should be considered when designing the PKI architecture?
Lifecycle management of certificates including design, manufacturing, certificate registration, revocation and updating to decommissioning (i.e., disconnection from services, purging of data, reset to factory configuration) is generally more challenging than for human users:
- Devices can be used for decades and may change hands in some cases. Software versions and parameters may be out of date, as well as customer specific.
- How do you keep track of all your devices, users, and certificates? Certificate inventories that provide visibility into the chain of trust, current location and expiration times grow over time and must be cross border scalable.
- How can field devices be accessed to renew certificates? For example, by maintenance personnel? Connectivity in the field is often intermittent and may be dependent on the owner’s IT/OT network architecture
- Device certificates must be compatible with upstream or downstream PKI systems because components can be part of larger systems. There are physical production requirements such as keeping track of certificates that have been issued, but where devices have never been shipped (e.g., due to quality issues). Also, because operations technology (OT) security typically prohibits direct internet connectivity of assembly lines, a secure batch certificate issuance at regular intervals must be enabled, possibly through factory certificate authorities and secure gateways. Key generation on electronic control units can be time-consuming and become a bottleneck in production, reducing overall manufacturing capacity
Limited processing power, RAM memory and storage of devices can all have impact, such as making asymmetric encryption impractical and necessitating symmetric key exchanges.
PKI vendors and service providers
Some vendors only offer components (including a few open-source products) such as a private CA or certificate administration software, while others provide complete systems as well as managed services (PKIaaS). Aside from large consultancies and MSSPs, smaller firms specialized on PKI exist, such as Achelos, IDependant, or PKI Solutions.
Entrust (nCipher), Fortanix, Futurex, IBM, Swissbit, Thales, Utimaco and Yubico are among the leading hardware security module (HSM) vendors. HSMs are typically connected to PKI applications through the PKCS#11 standard and used for secure and fast cryptographic operations (like request validation, signing, decryption, key generation) and key storage, so that private keys don’t have to be stored in RAM.
Some factors to consider when procuring a PKI environment
A sound decision should be based on a technical and commercial assessment of multiple solutions. When selecting PKI systems, the following requirements have emerged as recurring themes.
- Adherence to target PKI architecture and usage scenario processes, e.g.,
- number of CA tiers
- on premise / cloud deployment of CAs for decentralized factory networks
- private or public root CAshosting of CAs and certificate management applications
- Quality assurance system for testing changes (possibly with emulated HSMs)secure injection of initial certificates in factories for devices under production
- other considerations include connection to MES/SCADA systems, administration of distributed certificate authorities, availability requirements, backup systems, key storage, management of trust lists. For example, should the HSM be dedicated to customer’s keys, or should it being shared If shared, transferring from a managed service provider may be difficult
- Compatibility with existing and planned device architecture, particularly for micro controllers (e.g., ARM, Infineon) and embedded RTOS (possibly without trusted platform module/TPM),
- Integrations into the customer specific Dev(Sec)Ops tool chain and IT infrastructure, specifically
- common IoT mobile device management solutions (e.g., Intune or SOTI)
- cloud infrastructure IoT platforms to orchestrate device management and for data storage and processing (for example, Azure IoT Hub, AWS IoT, PTC ThingWorx, Wipro)
- existing Active Directory or other identity services
- Experience with full device lifecycle management and IoT infrastructure design by the system provider, such as the establishment of new manufacturing lines or production facilities in relevant countries, or updates of operating systems or application patches for bug fixes and feature enhancement. How many keys has the vendor’s CA already issued to how many field devices? Which applications, which sectors and when have these devices been used by end customers? Is it possible to contact reference customers, or visit data center operations?
- Common protocols and standards for auto enrolment, provisioning, certificate request, validation, key storage and communication are supported (For example, ACME, CoAP, CEP/CES, CMPv2, CRL, CRMF, EST, MQTT, NDES, OCSP, OPC UA, PKCS#10 / #12, RFC8628 OAuth2.0, REST, SCEP, SPKAC)
- Fulfillment of generally recommended security practises ( as listed by the Cloud Security Alliance IoT Working Group, IOT Security Foundation, NIST SP 800-160 on Systems Security Engineering, NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline or Microsoft) for PKI infrastructures, such as formal key ceremonies for all elements of the CA hierarchy or possibility of biometric authentication. MFA is obvious, but which authenticators/tokens are supported in which situations?
- Support of strongest and IoT-specific ciphers, hashing algorithms, and key sizes (e.g., Ascon, ECDSA, Edwards, RSA, SHA-2/3)
- Is it necessary for components or services to have specific certifications (e.g., CC EAL 4+, eIDAS, FIPS L2/3…, PCI DSS, SOC2 Type 2) or to comply with industry specific standards (e.g., automotive industry vehicle-to-X, PSDS2, HIPAA, NATO Restricted) ? If so, will system and service providers such as data center operators be able to pass these audits?
- Custom X.509 or other certificate templates and policies (e.g., storage rules)
- SLAs, e.g., response times and availability, for support cases and services
- Price-/performance ratio: Licensing models differ significantly in terms of one-time costs for setup and implementation of use cases, subscription fees, costs per authority and costs per certificate or entity. Some players have optimised solutions for global mass manufacturing (“scalability”), while others are cost-effective at volumes as well. Will the supplier as general contractor, provide a turnkey solution, or what exactly is required from customer side for all interfaces to function properly?
Summary
PKI is a de facto standard solution for establishing machine identities and ensuring secure use of (I)IoT devices with reasonable computing power. There are numerous vendors and service providers offering solutions, many of whom have demonstrated the ability to set up or operate PKI environments for billions of connected devices.
Choosing a PKI system, in our experience, is a complex project in which the target concept evolves over time and the list of vendors is whittled down iteratively based on a better understanding of the offerings. Knock-out criteria emerge that were not obvious at first, and features that were thought to be unique are sometimes re-evaluated as making no meaningful difference.
Specialized sourcing advisory with experience in PKI projects for (I)IoT manufacturers can help save time and internal resources while also achieving a good price-/performance ratio.
Thanks to Dall-E2 for helping us with the graphics design
Please remember: This article is based our knowledge at the time it was written – but we learn more every day. Do you think important points are missing or do you see the topic from a different perspective? We would be happy to discuss current developments in greater detail with you and your company’s other experts and welcome your feedback and thoughts.
And one more thing: the fact that an article mentions (or does not mention) a provider does not represent a recommendation from CyberCompare. Recommendations always depend on the customer’s individual situation.
