設備與命令互通
我想創建一個智能家居項目，並在其中購買了一些簡單的射頻模組。這些模組不支持開箱即用的加密，但我想將它們連接到我將程式為使用加密的設備（例如 AES）。
現在的問題是，由於我將發送許多使用相同密碼加密的相同消息（數字 I/O 引腳），因此輸出的加密消息將是相同的。因此，如果有人在嗅探流量，他/她將能夠傳輸該加密消息，而我的 C&C（命令和控制）設備會認為該消息來自內部並根據該消息執行某些操作。4 路握手並沒有削減它，因為即使不知道消息是什麼，也可以廣播它以達到某些結果。
**問題：**在這種情況下使用的最佳實踐/加密是什麼？我是否應該在原始消息中添加一個隨機字元串，然後在另一端解析該消息並提取我需要的資訊？
請記住，所有終端上的設備都是低記憶體的低計算設備（如果你願意，可以使用某種 Arduino）。因此，我需要一個安全的加密解決方案——即使使用者可以嗅探數據——使用者也無法使用它。
在這個問題的幾個方面中，我將只介紹防止命令重放的保護。
一種常見的技術（在幾種技術中）是將命令綁定到一個隨機數，接收命令的從設備只接受一次。隨機數包含在保護命令完整性的MAC或公鑰簽名算法的輸入中。
當雙向通信可能時，nonce 可以簡單地是一個真正的隨機值，其寬度足夠大，很可能不會重複（例如，16 字節），由從設備生成並在發送命令之前發送給主設備。然後從機接收命令，檢查包含在命令中的 MAC 或簽名（準備在包括 nonce 的數據上，作為實際命令中數據的前綴），並且只有在 MAC 或簽名檢查時才執行命令。然後從站不再接受執行另一個命令，直到它生成另一個隨機數。
從純重放的角度來看，這是安全的。然而，對手可能滿足於推遲執行命令（而不是第二次執行）。想想車庫門：對手等待房主回家並發送開門命令；對手擷取該命令，直到最後 CRC 的中間，並從那一刻開始阻塞無線電通道。該命令因 CRC 錯誤而被從機忽略，並且不會被執行。在攻擊者停止干擾很久之後，然後用重新計算的 CRC 重新發送命令；阿布拉卡達布拉門打開了！令人驚訝的是，一些複雜的安全通道協議對活躍的對手可以延遲一幀的時間沒有限制（也許插入重複的虛擬請求以保持某些連結處於活動狀態），並且容易受到這種攻擊。有一個簡單的對策：我們可以對隨機數的有效性設置一個時間限制，比如秒，由從機強制執行，從隨機數的發送開始計算；並且 nonce 需要是不可預測的（而不僅僅是唯一的）以阻止攻擊的某些變體。
這很好，但是隨機數需要兩個額外的幀（從請求隨機數的從機；從具有隨機數的從機）。至少減少成本幀數量的一種選擇是在發送的每個幀中嵌入一個新的隨機數，如果在延遲內接收，則適用於下一幀；因此，在一系列命令中，成本是兩個初始幀，加上添加到其他幀的隨機數的大小。非常小心，可以使用關於當存在經過身份驗證的活動時隨機數如何演變的精確約定來消除以後的成本。
注意：如果攻擊者可以訪問沒有可靠 TRNG 的從設備的電源（早期智能卡中的情況），那麼使 nonce 不可預測甚至不重複出現的問題是出了名的困難。用本地密鑰加密保存在 EEPROM 中的計數器的解決方案表面上似乎可行（甚至允許使用兩倍窄的隨機數，以增加對重用的保證）；但是有一個問題是在變化過程中製作一個不會在功率損耗上倒退的計數器；EEPROM 對同一位置重複寫入的耐受性有限；以及儘管存在旁道，但保持密鑰秘密的基本困難。