翻译: https://www.hivemq.com/blog/mqtt-security-fundamentals/
在IOT场景中,设备资源受限(计算能力、耗电量等)和网络受限(带宽、稳定性等),这些因素使得高安全性和高可用性更加难以权衡。
Mqtt的安全可以在应用层、传输层和网络层进行保证,如下图所示:
正确:客户端按一定规则生成签名作为密码,然后Broker进行验签;
错误:用户名和密码直接使用明文;
客户端使用Broker证书校验Broker身份;Broker使用客户端证书校验客户端证书;
为了限制客户端发布和订阅Topic的权限,Broker必须具备Topic权限管理的功能,而且这些权限可以在运行时动态配置和调整的。对于每个客户端,Topic的权限管理主要包括:
权限校验不通过时的处理:
MQTT 3.1.1协议并没有提供一种方式让Broker通知客户端没有Publish权限。
The current MQTT 3.1.1 specification does not define a broker-independent way to inform clients about the unauthorized publish, except disconnecting the client, which may be improved in upcoming MQTT versions.
在SUBACK消息中返回错误码和错误消息即可。
In the case of subscribing to a topic, the broker needs to acknowledge each subscription with a return code. There are 4 different codes for acknowledging each topic with a granted QoS or sending an error code. So if the client has no right to subscribe a specific topic, the broker can notify the client that the subscription was denied.
采用这种方式时,建议 只针对消息体加密,不要加密消息头中的其它字段(避免Broker进行一次解密)。主要使用场景是 设备资源受限无法采用TLS机制时。
E2E encryption is broker implementation independent and can be applied to any topic by any MQTT client. If you can’t use authentication and authorization mechanisms or you are using a public broker (like the MQTTDashboard), you can protect your application data from suspicious eyes and MQTT clients.
A Client-to-Broker approach makes sure that the payload of the message is encrypted in the communication between one client and the broker. The broker is able to decrypt the message before distributing the message, so all subscribers receive the original, unencrypted message. This may be a good alternative if you can’t use TLS and want to protect important data from eavesdroppers on the publishing side. (Please read our post about TLS to make sure you understand the risks of not using TLS!) The trusted subscribers are connected via a secure channel (TLS) and thus they are allowed to receive the data in plain text.
原因:快速、安全且消耗资源小
Message Authentication Code Algorithms (like HMAC) are typically very fast compared to digital signatures and provide good security if the shared secret key was exchanged securely prior to the MQTT communication. HMAC calculates the MAC with a cryptographic Hash Function and a cryptographic key. Only senders which know the secret key can create a valid stamp. The disadvantage is, that all clients who are aware of the secret key can sign and verify, since the same key is involved for both processes.
HMACs work great with MQTT PUBLISH messages and can be used securely even if you don’t have TLS deployed. HMACs are pretty fast to calculate and don’t use much resources on constrained devices.
原因:快速但不安全
原因:极特殊情况使用
Digital Signatures use public / private key cryptography. The sender signs the message with its private key and the receiver validates the stamp (signature) with the public key of the sending client. Only the private keys can create the signature and thus it’s not possible to fake the signature if an attacker did not obtain the private key.
As seen in the client certificate blog post, provisioning and revocation of public / private keys is a challenge and adds complexity to the system. Another challenge is, that in Publish / Subscribe Systems like MQTT, the receiver of a message typically is not aware of the identity of the sender, since the communication is decoupled via topics. If it’s guaranteed that only a specific client can publish to a specific topic (e.g. by authorization mechanisms), digital signatures may be a good (and secure!) fit, though.
结论:建立连接阶段,TLS很消耗CPU
https://www.hivemq.com/blog/how-does-tls-affect-mqtt-performance/
联系客服