Any point in protecting constrained IoT devices?
A constrained IoT device has very limited processing and communication capabilities, making it totally harmless and needless to protect and secure… or? Actually, it is rather the opposite. We have already witnessed numerous cybersecurity attacks where insufficiently secured IoT devices were targeted and used for malicious actions, like DDoS attacks, or just as an entry point to other, more sensitive, devices in the same network.
Today it is quite straightforward to secure an IoT device with Public Key Infrastructure (PKI) and digital certificates. But sometimes IoT devices are too constrained even for the most efficient standard PKI certificate management protocols in the market. Do you have this challenge with your IoT application? If so, you are not alone.
PKI is the de-facto, and sometimes even regulated, the standard for ensuring device authentication, data integrity and confidentiality, and for implementing a zero-trust IoT architecture. A broad selection of standard PKI certificate management protocols is available for enrolling and provisioning certificates in telco and IT equipment and in IoT devices. They have been developed at different points in time and to serve different purposes and types of devices. EST (Enrollment over Secure Transport) protocol, for instance, is one of the later developments that was designed to be a replacement for SCEP (Simple Certificate Enrollment Protocol). It is recognized for its security features and ease of use and enables great automation and is for those reasons many times a good choice for use in IoT applications and to include in the device specification for IoT device vendors.
There are however many IoT devices for which EST – just as the other standard management protocols in the market – is too heavy and cannot be supported. I am referring to very resource-constrained devices like battery-powered sensors and similar that have limited capacity in terms of processor, memory and communication.
This brings a challenge both for the IoT application owner and the vendors of IoT devices. The former wants to have a zero-trust design and include only properly secured IoT devices in the IoT application. The latter wants to equip the IoT devices with market-accepted security capabilities in order to increase the value of the devices and ensure that they can be used in a zero-trust IoT application.
So, what do you do when you are in this situation?
One option is obviously to rely on some solution that is simple enough for constrained IoT sensors to handle but less secure than PKI. Based on the continuous increase of IoT security attacks on a global basis and the costs associated with them and also on increasing IoT security regulations, this is not the recommended way, but rather a mediocre workaround solution.
Another possibility is to go with some vendor-proprietary solution. There are such solutions available that are good enough from a security perspective. The major drawback with this approach is however the risk of vendor lock-in. The IoT application owner does not want to be stuck with a certain vendor, and the device maker will not limit the value of the products by implementing non-interoperable security protocols. Hence, this is also not a recommended solution.
EST over secure CoAP (Constrained Application Protocol), abbreviated “EST-coaps”, is instead what you should turn your gaze to. EST-coaps is a PKI certificate management protocol developed specifically for constrained IoT devices that can be used for secure bootstrapping and certificate enrollment to such low-resource devices in a way similar to how other standard certificate management protocols are used for more powerful devices. EST-coaps is a proposed Internet standard, RFC 9148, that is supported by Nexus Certificate Authority (CA), Certificate Manager.
The SecureCare project demonstrated the use of EST-coaps in a zero-trust healthcare IoT application, where very resource-constrained IoT sensors securely transmitted data to the backend. The project had a strong requirement for vendor independence and the use of standard protocols.
So, if your IoT application requires resource-constrained IoT devices that cannot handle the common certificate management protocols, you do not need to make a compromise on security or vendor independence. My recommendation is to make sure that EST-coaps is in the requirements specification of these devices used in your IoT application.
And my hint to all vendors of constrained IoT devices – make sure to implement EST-coaps to ensure that your devices can be secured with PKI and used in zero-trust IoT applications.