Mqtt精髓系列之安全

WindySky 2020-01-15

展開全文

翻譯： https://www./blog/mqtt-security-fundamentals/

面臨的挑戰(zhàn)

　　在IOT場景中，設備資源受限（計算能力、耗電量等）和網絡受限（帶寬、穩(wěn)定性等），這些因素使得高安全性和高可用性更加難以權衡。

安全方案概覽

　　Mqtt的安全可以在應用層、傳輸層和網絡層進行保證，如下圖所示：
這里寫圖片描述

身份認證

方式一：用戶名和密碼

　　 正確：客戶端按一定規(guī)則生成簽名作為密碼，然后Broker進行驗簽；
　　 錯誤：用戶名和密碼直接使用明文；

方式二：TLS/SSL

　　客戶端使用Broker證書校驗Broker身份；Broker使用客戶端證書校驗客戶端證書；

權限校驗

　　為了限制客戶端發(fā)布和訂閱Topic的權限，Broker必須具備Topic權限管理的功能，而且這些權限可以在運行時動態(tài)配置和調整的。對于每個客戶端，Topic的權限管理主要包括：

允許的Topic（明確Topic、帶有通配符的Topic）;
允許的操作（發(fā)布、訂閱和兩者）；
允許的Qos等級；

權限校驗不通過時的處理：

無Publish權限的處理

Broker直接斷開與客戶端的連接；
Broker向發(fā)布方返回正常的響應，但是不再向訂閱方投遞消息；

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.