|
翻译： https://www./blog/mqtt-security-fundamentals/ 面临的挑战 在IOT场景中，设备资源受限（计算能力、耗电量等）和网络受限（带宽、稳定性等），这些因素使得高安全性和高可用性更加难以权衡。 安全方案概览 Mqtt的安全可以在应用层、传输层和网络层进行保证，如下图所示：
 身份认证 方式一：用户名和密码 正确：客户端按一定规则生成签名作为密码，然后Broker进行验签；
错误：用户名和密码直接使用明文； 方式二：TLS/SSL 客户端使用Broker证书校验Broker身份；Broker使用客户端证书校验客户端证书； 权限校验 为了限制客户端发布和订阅Topic的权限，Broker必须具备Topic权限管理的功能，而且这些权限可以在运行时动态配置和调整的。对于每个客户端，Topic的权限管理主要包括： - 允许的Topic（明确Topic、带有通配符的Topic）;
- 允许的操作（发布、订阅和两者）；
- 允许的Qos等级；
权限校验不通过时的处理： 无Publish权限的处理 - Broker直接断开与客户端的连接；
- Broker向发布方返回正常的响应，但是不再向订阅方投递消息；
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. 无Subscribe权限处理 在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机制时。 场景1：End-to-End (E2E)  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. 场景2：Client-to-Broker  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. 数据完整性校验 方式1：使用MACs（推荐） 原因：快速、安全且消耗资源小 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. 方式2：使用Checksums （不推荐） 原因：快速但不安全 方式3：使用Digital signatures 原因：极特殊情况使用 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/SSL补充 TLS对Mqtt性能损 结论：建立连接阶段，TLS很消耗CPU
https://www./blog/how-does-tls-affect-mqtt-performance/
|
