Since its early days of inception, Public Key Infrastructure (PKI) protected our internet-based economy. From simple web-browsing to complicated e-commerce, PKI has secured internet transactions on a global scale, as “the pillar-of-trust”.
But what about the internet of tomorrow?
Until now, internet transactions employed a client-server model, where human users primarily communicated with web servers. In the Internet of Things (IoT), this client-server model is widely distributed, wherein devices communicate with other devices (machine-to-machine or M2M) and the cloud servers (machine-to-cloud or M2C) without human intervention.
When devices communicate autonomously, both the value and risk are tied directly to the degree of trust we attribute to them. In that sense, trust underpins the enormous economic and social promises of the IoT on an industrial scale (known as the Industrial IoT or IIoT). Trust attributed to a device determines the integrity of the data that it communicates. Just imagine the impact of insulin pumps or pacemakers relying on data from spoofed sources. Ensuring trust is thus all the more important to secure the IoT. The question is, as a tried and tested open standard, to what extent can PKI help?
In M2M communications, devices must mutually authenticate. This can be done in multiple ways.
Due to its robust trust model, much of the security community today is gravitating towards PKI to secure IIoT. However, PKI certificates are considerably resource-intensive, which is a concern for resource-constrained IIoT devices. Issuing, managing, and revoking certificates is also a concern in highly scaled and autonomous IIoT scenarios.
The pressure is high to innovate and evolve traditional PKI to adapt to the massive scale and diversity of devices, data, and connections in IIoT. The evolution must address both PKI certificate standards and certificate lifecycle management.
X.509 is the most widely used PKI certificate standard. X.509 certificates use a hierarchical format to embed the necessary information to certify the machine. Each certificate has a field for the validity period, and the associated public key issued by the CA.
Due to its vast popularity, the X.509 standard is experiencing rapid adoption among manufacturers of IoT devices and platforms. Some device manufacturers install the public/private key pair, which is certified and signed by the manufacturer. When various vendors along the supply chain—e.g., chipset manufacturers, OEMs, and the device owners—add their respective signed certificates, the resulting chain of trust drastically improves device integrity and authenticity.
The robust integrity of X.509 certificates comes at the cost of their size, which is a major drawback for low-footprint IIoT devices like sensors, microcontrollers, etc. Unless adequate storage exists for the encrypted keys, and sufficient power and CPU, implementing X.509 certificates could pose a challenge.
The IEEE 1609.2 certificate is an emerging standard to address the unique requirements of IIoT. The 1609.2 certificate is half the size of X.509. Using elliptic curve cryptographic (ECC) algorithms, IEEE 1609.2 reduces computational overhead without sacrificing cryptographic strength.
Right now, the 1609.2 standard is primarily led by the US Department of Transportation (USDOT) to build a trust model for their connected vehicle program. It addresses various constraints specific to mobile endpoints in congested, low-bandwidth environments.
The IEEE 1609.2 certificates support certificate trust chaining and peer-to-peer certificate distribution, which are relevant to connected vehicle-to-everything (V2X)—which includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), etc.—communications. For M2M scenarios in general, involving one-to-many and many-to-one data transfers, 1609.2 certificates are useful. But, they are not suited for persistent security sessions.
Since the public internet and enterprise IT applications use server-authentication, PKI was originally designed to issue certificates only to the web servers. The number of certificates needed was less, and certificate authorities were only a handful.
In IIoT, that legacy PKI scheme has been totally disrupted. To prevent unauthorized communications with rogue endpoints, the communicating device endpoints must authenticate each other. Although certificates can provide a robust way of mutual authentication, it requires every device to have its own certificate. As the number of IoT devices scale to millions, so does the number of certificates. Thus, manual provisioning and management of certificates of legacy PKI can’t scale for IIoT. Currently, many newer ways of certificate management are emerging to ease the complexity of PKI adoption.
However, whether designing a chip, electronic board, or a device, when it comes to the trust model, we can’t ignore PKI. As a well-established, interoperable trust framework, our focus should be to resolve any shortcomings of PKI certificates instead of bypassing them altogether.
Sravani Bhattacharjee has been a Data Communications technologist for over 20 years. She is the author of “Practical Industrial IoT Security,” the first released book on Industrial IoT security. As a technology leader at Cisco till 2014, Sravani led the architectural planning and product roadmap of several Enterprise Cloud/Datacenter solutions. As the principal of Irecamedia.com, Sravani currently collaborates with Industrial IoT innovators to drive awareness and business decisions by producing a variety of editorial and technical marketing content. Sravani has a Master's degree in Electronics Engineering. She is a member of the IEEE IoT Chapter, a writer, and a speaker.
Visualizar em dispositivo móvel
Centro de privacidade |
Termos e condições
Mapa do site
Direitos autorais © 2021 Mouser Electronics, Inc.
A Mouser® e a Mouser Electronics® são marcas comerciais da Mouser Electronics, Inc. nos EUA e/ou em outros países.
Todas as demais marcas comerciais são de propriedade de seus respectivos proprietários.
Matriz e centro de logística em Mansfield, Texas, EUA.