As IoT continues to permeate the corporate technological zeitgeist good security is, and should be, paramount at application level. Even data breaches in projects that deal with fairly innocuous data can affect customers trust in your ability which can arguably have a greater affect on the bottom line.
As with HTTP there are a number of security mechanisms that can be used to allow for authentication and authorisation.
Note: The difference between authentication and authorisation. A swipe card magnetic strip can authorise access to a building but without a name and picture on the card security staff would not be able to authenticate the user. For a technical example: HTTP API keys can authorise access to an API but not authenticate the requesting user.
You may be aware of the various security options geared towards IoT for implementing authentication and authorisation when using HTTP such as: Basic Authentication, API keys, and OAuth.
Client ID and Password
MQTT, like HTTP, requires being aware of the client as well as the server when considering security. For instance, with HTTP, TLS can be expensive in both bandwidth and compute power when working with smaller devices due to the handshaking required.
Servers (brokers) can require a username and password combination, similar to HTTP basic authorisation, before being able to connect. The self same username can then be used to restrict access to topics.
The username/password combination alone is insecure as it is transmitted in plaintext and must be used in conjunction with TLS.
Transport Layer Security (TLS)
TLS and Secure Sockets Layer (SSL) provide an encrypted communication channel between the server and client. Each connection is started with a handshake in which, typically, the server’s x.509 certificate is exchanged and validated to verify the identity.
Whilst TLS may sound like a done deal there is a drawback in terms of CPU usage and communication overhead in the handshake; however, MQTT does offer methods of reducing this such as persistent sessions which reduces the TLS handshake overhead to negligible levels.
If the device memory is too constrained with insufficient resources to perform the necessary encryption for TLS it is recommended to encrypt just the payload if it includes sensitive data, and, at the very least, hash or encrypt the password in the CONNECT message.
X.509 Certificates
As an added layer of security a client X.509 certificate can be deployed to devices to allow for authentication during the initial TLS handshake. Typically public/private certificates are deployed on the server to validate the HTTPS connection
Oldest comments (0)