If digital certificates are to be used, a protocol such as X.509 (IETF RFC 5280) provides effective secure digital identity authentication. A Public Key Infrastructure (PKI), on the other hand, maintains a list of trusted root certificates. Each certificate contains the device’s public key and is signed with the issuing authority’s private key. It can be validated using a cryptographic algorithm.
To establish a delegated chain of trust from the trusted root certificate authority, digital certificates are typically arranged in a chain in which each certificate is signed by the private key of another trusted certificate. This chain must return to a globally trusted root certificate. While this requires a lot of management control, there are many vendor options. Consequently, many organisations that setup and use IoT networks rely on external vendors for certificates and lifecycle automation.
A Hardware Security Module (HSM) may be used to establish a delegated chain of trust from the trusted root certificate authority. This can provide the safest secure, hardware-protected storage of secret data.
Depending on the device resources available and performance and security requirements, a Secure Element (SE) may be suitable for use in some IoT devices. A SE can be implemented as a discrete hardware IC or integrated in the application IC. Often used standalone on banking or ID systems, these SE are designed for efficient and frugal use of system resources making them suitable for use in low-end IoT devices. Typically having cryptographic capabilities, the SE can handle various functions relevant to authentication and authorisation, including establishing a hardware root of trust (RoT) and managing secure boot-up as well as device identification.
The SE can be used at various points along the supply chain to verify that the device has not been incorrectly modified. It can store cryptographic keys securely in tamper-resistant hardware. The keys are generated within the SE itself and are therefore protected from being retrieved by external programs. If appropriate, the SE can be used simply as a hardware key store without utilising its RoT and secure boot capabilities.
Choosing the Right Model
To determine the most suitable model, it is critical to assess the level of security needed for the IoT system. Factors such as data sensitivity, risk tolerance, and compliance regulations can help to choose between the different models.
It is also important to ensure that the chosen model allows scalability to handle the growing number of devices, users, and access requests as the IoT implementation grows, without compromising performance or security.
It is important also to bear in mind that known IoT device constraints such as limitations on computing power and memory can impact the feasibility of certain authorisation models. Lightweight protocols like MQTT or CoAP (Constrained Application Protocol Security) may be suitable for resource-constrained devices.
It is also important to ensure that the chosen authorisation model integrates with existing infrastructure and systems and can accommodate future policy updates, new device types, and integration with emerging technologies. Most of the authorisation model implementation is done on the server, so the focus on devices is really put on the authentication.
Conclusion
Proper implementation of IoT authentication and authorisation has many beneficial effects on IoT security. However, choosing the right method can be challenging, and the wrong choice can significantly increase risks.
In terms of authentication, some risks can be mitigated by securely storing the keys and credentials safely on the device and following best practices around key storage.
As far as authorisation is concerned, scalability is critical and the chosen approach must integrate with legacy systems, as well as offering flexibility and future proofing.
Ultimately, authentication and authorisation, based on immutable and provable device identities, are critical to establish trust between IoT devices and the application server, to protect the ecosystem and the sensitive data within it against hacking and other malicious activity.