Comparison of security level and current consumption of security implementations for MQTT

Abstract: IoT is a rapidly growing area with products in the consumer, commercial and industrial market. Collecting data with multiple small and often battery-powered devices sets new challenges for both security and communication. There has been a distinct lack of a IoT specific communication protocols. The industry has had to use bulky interfaces not suitable for resource-constrained devices. MQTT is a standardised communication protocol made for the IoT industry. MQTT does however not have built-in security and it is up to the developers to implement a suitable security countermeasure. To evaluate how different security countermeasures impact MQTT in complexity, current consumption and security the following research questions are answered. How do you derive a measurement from the SEF that can be compared with a current consumption measurement? Which level of security, according to the SEF, will RSA, AES and TLS provide to MQTT when publishing a message to a broker? What level of complexity is added to MQTT when using chosen security countermeasure? Which of the analysed security countermeasure upholds an adequate security level while also having a low current consumption? To answer the above research questions an experiment approach has been used. Implementations of TLS, RSA and AES have been evaluated to measure how they affect the security level and current consumption of an MQTT publication, compared to no security countermeasures at all.Both RSA and AES had the same security level, but the current consumption for RSA was four times higher. The experiment showed that the security level is significantly higher for TLS, while it also has the highest current consumption. The security countermeasure evaluated differs greatly. TLS provides complete protections, while RSA and AES lacks authentication and does not ensure integrity and non-repudiation.Even if the current consumption for TLS is higher, the security it provides make it unreasonable to recommend any of the other security countermeasure implementations.