Choosing the Right IoT Protocol: A Security Analysis on MQTT, CoAP, and HTTP

In this era of rapid technological advancement, selecting the appropriate communication protocol for your IoT ecosystem goes beyond optimising data transfer efficiency; it extends to safeguarding the confidentiality, integrity, and availability of sensitive information.

To help you with choosing the right protocol, we have compiled a multipart guide. In this series, we will take up different aspects like fundamental concepts, performance analysis and security analysis of MQTT, CoAP and HTTP, draw a comparison between respective protocols and provide you with different matrics to make an informed decision.

In Part 1 of our multipart series, "Choosing the Right IoT Protocol: A guide on MQTT, CoAP and HTTP" we explored the fundamental concepts, data flow intricacies, and contextual use cases associated with MQTT, CoAP, and HTTP. In Part 2,  "Choosing the Right IoT Protocol: A Performance Analysis of MQTT, CoAP and HTTP"  we explored the performance aspect of each of these protocols.

What to expect:
In Part 3 of our multipart series, we will be exploring the security aspects of MQTT, HTTP, and CoAP. We will be going through the different authentication options provided by respective protocols and effective measures to secure message payload.

Why Security Matters?

Security is a critical concern in IoT due to the interconnected nature of devices and potential vulnerabilities. In the context of communication protocols like CoAP, MQTT, and HTTP, ensuring security is imperative. CoAP uses measures such as preshared keys, Raw Public Key and certificates for authentication and encryption. MQTT mandates password-based authentication, certificates, and access controls for security. HTTPS, authentication, authorisation, input validation, and secure APIs are essential for HTTP-based IoT. Overall, securing IoT communication prevents unauthorized access, data breaches, and tampering, fostering trust and reliability in IoT ecosystems.

MQTT Security Measures

To ensure the integrity and confidentiality of IoT data, MQTT offers robust security measures that safeguard communication between MQTT brokers and clients. In this section, we will explore MQTT's authentication options and the techniques used to secure MQTT broker and client communication.

Authentication Options provided by MQTT

• Username/Password: MQTT supports basic username/password authentication, where clients provide their credentials during the connection setup. This mechanism verifies the identity of clients and grants access based on valid credentials. However, it's important to note that username/password is not the most secure authentication method as maintaining a password database comes with its own security risks, and other additional security measures are recommended. Look at the example below for setting up a username and password using paho mqtt client

import paho.mqtt.client as mqtt
Client = mqtt.Client();
# set username and password for authentication
client.username_pw_set("myusername", "my_pass")

• X.509 Certificates: MQTT also supports X.509 certificate-based authentication, which involves the exchange of digital certificates between clients and brokers. This method leverages Public Key Infrastructure (PKI) and offers stronger authentication compared to username/password. It ensures that only trusted clients with valid certificates can connect to the broker.
• OAuth 2.0: Some MQTT brokers extend support for OAuth 2.0 authentication, enabling clients to use OAuth 2.0 tokens to authenticate themselves. This integration with OAuth 2.0 enhances security and simplifies the authentication process, especially in scenarios where clients are already integrated with OAuth-based identity providers.

Securing MQTT Broker and Client Communication

• Transport Layer Security (TLS/SSL): TLS (Transport Layer Security) or its predecessor SSL (Secure Sockets Layer) is fundamental to securing MQTT communication. By enabling TLS/SSL, the data exchanged between MQTT brokers and clients is encrypted, preventing unauthorized interception and eavesdropping. It ensures data confidentiality and integrity, safeguarding sensitive IoT information.
• Message-Level Security: In addition to securing the communication channel, MQTT can implement message-level security by encrypting the payload of MQTT messages. We will discuss the common encryption algorithm in the later section.
• Role-based Access Control: Role-based Access Control or Access Control Lists involves defining different roles or levels of access for MQTT clients based on their responsibilities and privileges within the IoT ecosystem. This ensures that each client can only perform actions that are appropriate for their role and prevents unauthorized activities. By assigning roles such as "admin," "user," or "guest," administrators can finely control which clients can publish, subscribe, or manage topics and resources.
• Intrusion Detection and Logging: Deploying intrusion detection systems (IDS) allows continuous monitoring of MQTT network activities for any unusual patterns or behaviour. IDS can promptly alert administrators to potential security breaches or suspicious activities. Comprehensive logging of MQTT communication and client interactions provides valuable information for auditing purposes, helping identify and respond to security incidents effectively.

CoAP Security Measures

CoAP offers robust security measures that protect communication in resource-constrained environments. In this section, we will delve into CoAP's authentication options and the techniques used to secure CoAP client and server communication.

Authentication Options provided by CoAP

• Pre-Shared Key (PSK) Authentication: CoAP supports Pre-Shared Key authentication, allowing clients and servers to authenticate each other using a shared secret. PSK is a simple and efficient authentication method, suitable for constrained devices where complex authentication mechanisms may not be feasible. However, it requires secure management of keys to avoid compromise.
• Raw Public Key (RPK) Authentication: CoAP also provides Raw Public Key authentication, where clients and servers use asymmetric cryptographic keys for authentication. RPK offers enhanced security compared to PSK, as it leverages public and private key pairs. However, this method demands secure key storage and key distribution mechanisms.
• Certificate-Based Authentication: Certificate-based authentication is another option supported by CoAP. This method utilizes X.509 certificates, enabling secure identification and authentication of clients and servers. Certificate-based authentication is particularly suitable for scenarios where a Public Key Infrastructure (PKI) is already in place.
• NoSec (No Security): In this mode, CoAP operates without any security measures, leaving communication vulnerable to eavesdropping, unauthorized access, and data manipulation. This mode is suitable for scenarios where security is not a concern, but it's generally not recommended for most IoT deployments.

Securing CoAP Client and Server Communication

• DTLS (Datagram Transport Layer Security): CoAP incorporates DTLS, which is the lightweight version of TLS (Transport Layer Security), to secure communication over unreliable transport protocols like UDP. DTLS ensures end-to-end encryption and data integrity, preventing unauthorized access and tampering of messages.
• CoAP Proxy and Firewall Considerations: When deploying CoAP in larger networks, the use of proxies and firewalls should be carefully considered. Proxies can provide additional security measures by filtering, caching, and authenticating CoAP messages before forwarding them to the intended servers.
• Message Integrity Verification through CoAP Options: CoAP offers an innovative approach through custom CoAP options to verify message integrity. By incorporating a hash or cryptographic checksum as a CoAP option within the payload, each message carries its own digital fingerprint. This fingerprint is validated at the receiving end, ensuring that the message hasn't been tampered with during transit. This technique seamlessly aligns with CoAP's lightweight nature, as it doesn't require additional overhead

HTTP Security Measures

HTTP offers various security measures. In this section, we will explore the authentication options provided by HTTP and the techniques used to secure HTTP client and server communication.

Authentication Options provided by HTTP

Basic Authentication: HTTP supports basic authentication, where clients provide their credentials (username and password) in the request header. While simple to implement, basic authentication transmits credentials in base64 encoding, which can be susceptible to interception if not used with additional security measures like TLS/SSL.

• Digest Authentication: To address the security concerns of basic authentication, HTTP introduces digest authentication. This method uses a challenge-response mechanism where the server sends a nonce (number used once) to the client, and the client sends the hashed credentials in the subsequent requests. Digest authentication provides better security compared to basic authentication.
• Token-Based Authentication: Token-based authentication has become popular in web applications and is applicable to HTTP in the IoT context. In this method, clients obtain a unique token from an authorization server after successful authentication. This token is then sent in the Authorization header for subsequent interactions with the server.
• OAuth 2.0: OAuth 2.0 is a widely adopted authorization framework for HTTP-based applications. While not an authentication method itself, OAuth 2.0 allows clients to obtain limited access to resources on behalf of a user. It is commonly used to delegate access to APIs and IoT services. Similarly, JWT token authentication is also widely used to authenticate communication.

Securing HTTP Client and Server Communication

• Transport Layer Security (TLS/SSL): A fundamental security measure for securing HTTP communication is TLS (Transport Layer Security) or its predecessor SSL (Secure Sockets Layer). TLS/SSL ensures that data transmitted between the HTTP client and server is encrypted, preventing unauthorized interception and eavesdropping. Enabling TLS/SSL provides data confidentiality and integrity, enhancing overall security.
• Client Certificates: HTTP also supports client certificate-based authentication. In this approach, clients present their digital certificates during the SSL/TLS handshake to verify their identity. This method enhances security by ensuring that only trusted clients with valid certificates can access the server.
• HTTP Public Key Pinning: HTTP Public Key Pinning (HPKP) emerges as a strategic measure to bolster this trust. By including public key pins in HTTP response headers, IoT servers instruct clients to only trust specific public keys for future connections. This mitigates the risk of malicious servers or compromised Certificate Authorities (CAs) being used to intercept communication
• HTTP Content Security Policy: Content Security Policy (CSP) serves as a formidable defence mechanism in this regard. By defining a CSP, IoT applications can specify which sources of content are considered legitimate and safe to load. This prevents malicious code injection and unauthorized data retrieval by limiting the domains from which resources can be fetched. CSP, configured with proper directives, acts as a virtual guard, significantly reducing the attack surface and enhancing the overall security posture of IoT deployments relying on HTTP communication.

Securing Message Payload

We can implement message-level security by encrypting the message payload. This ensures that messages are end-to-end encrypted and even if the broker is hacked the attacker will not have access to the message contents. There are many encryption techniques, some of the common ones are:

Advanced Encryption Standard (AES)

AES is a symmetric encryption algorithm widely adopted for securing data. It uses the same key for both encryption and decryption. AES supports key lengths of 128, 192, or 256 bits. Longer key lengths typically provide more robust security.

Example: To encrypt data AES involves converting plain text to encrypted text using a secret key. To decrypt the same message the recipient uses the same secret key.

RSA (Rivest-Shamir-Adleman)

RSA is an asymmetric encryption algorithm that uses a pair of keys (public and private) for encryption and decryption. It is often used for secure key exchange and digital signatures.

Example: RSA involves generating a pair of keys - a public key and a private key. Now to encrypt a message we will use a public key. To decrypt the same message, the recipient uses the private key.

Triple DES (3DES)

A symmetric encryption algorithm that applies the Data Encryption Standard (DES) cypher three times with different keys. It provides improved security over the original DES.

Example: To encrypt data, the algorithm applies the Data Encryption Standard (DES) cypher three times sequentially: Encrypt with Key 1, Decrypt with Key 2, and Encrypt with Key 3. To decrypt the data, the process is reversed: Decrypt with Key 3, Encrypt with Key 2, Decrypt with Key 1.

Security Features Comparison Summary

Conclusion

In summary, It's worth emphasizing that all these protocols are secure when configured correctly. The key takeaway is that security should never be an afterthought in IoT deployments. Regardless of the chosen protocol, we recommend that people use TLS and either certificate-based authentication with secure storage of private keys for any protocol they choose.

I hope you gained valuable insights from this comparison summary. As we continue to come up with more interesting tutorials and maker content, we invite you to explore Bytebeam further and see how our platform can empower your projects.

Stay Tuned!