以低數據速率加密小數據包
我正在嘗試在我們的藍牙通信之上建構我自己的加密層。由於我們需要支持一些特定的功能，我們不能使用綁定。在加密方面我是初學者，所以我想由更有經驗的人來執行它。請查看我計劃的方法並指出任何缺陷或改進：
- 通信是在 iPhone 和藍牙外圍設備之間進行的。在任何連接開始時，iPhone 都會生成一個隨機的公鑰/私鑰對。公鑰將被發送到藍牙設備。
- 藍牙設備將生成一個隨機對稱密鑰，使用 iPhone 的公鑰對其進行加密並將其發送回 iPhone。
- 現在，所有未來的通信都將使用對稱密鑰進行加密/解密。
- 為藍牙設備生成一次並用於辨識授權使用者的安全密鑰被加密並從 iOS 設備發送到藍牙設備。如果密碼錯誤，則連接被終止。如果正確，iOS 設備現在可以通過加密數據包通信完全訪問藍牙設備。每個新連接都將有一個新的私鑰/公鑰對和一個新的對稱密鑰。
由於數據包最大為 20 字節，數據速率約為 1200 字節/秒，因此我計劃使用 AES256 CTR 加密對數據包進行加密，因為這具有加密數據與原始數據長度相同的優點。
我的方法是否存在一些我不知道的缺陷？我使用 CTR 的計劃是否存在缺陷，因此加密數據的長度與原始數據相同？有沒有更好的方法來完成我想要的？
編輯：
我對我的具體案例有幾個問題。
- 我只需要將在通信開始時傳輸的安全密鑰保密，否則攻擊者將無法進行任何類型的重放攻擊，因為每個新的連接會話都會生成新的安全密鑰。這是有缺陷的想法嗎？
- 使用 Diffie-Hellman 生成對稱密鑰，然後使用流密碼 (CTR) 加密通信，這是否安全？每個數據包都將使用一個新的計數器值（初始化向量）進行加密，該值不會被會話重用，該值也將與加密數據包一起發送，以便在另一端進行解密。我的理解是，只要我從不使用相同的初始化向量來加密兩個不同的數據包，這種方法就會非常安全。這是正確的想法嗎？我想要使用流密碼的主要目的是使我的加密數據長度與未加密數據長度相同。
- 由於上面的第 1 點，我是否可以安全地為整個會話加密的所有數據包使用相同的初始化向量，因為下一個會話將具有完全不同的對稱密鑰，或者這樣做會打開我的協議被攻擊者解碼，使他們能夠獲取第 1 點中提到的密碼？
編輯2：
根據 Thomas M. DuBuisson 的評論，我發現我的方法存在一些我以前沒有想到的問題。一個主要問題是我需要確保在藍牙設備上有一個可靠的隨機數生成器。鑑於他提出的觀點，並且在對如何與有限資源設備安全地交換密鑰進行了更多研究之後，我想到了另一種可能更容易利用可用資源的方法，我希望更安全一些。對不起，我在這方面缺乏經驗，但我正在努力學習我能做的，希望不要犯任何愚蠢的錯誤。
通常，交換/設置會話密鑰的廣泛使用的算法是 Diffie Hellman。在交換公鑰的過程中，會生成一個共享密鑰，該密鑰也可用於加密通信，無需額外的 AES。
我不知道您對非對稱加密的了解有多深——通常，使用了兩（三個）問題。它們都不是平凡因式分解、離散對數和橢圓曲線，後者通常與前兩者結合。
但是，我遺漏了一些有用的細節——您寧願使用快速加密（因為在這種情況下，我會推薦基於橢圓曲線的 Diffie Hellman，作為 ECDH）還是簡單的實現（標準 DH）。算法是 CCA 安全的重要嗎（DH 不是）。安全性應該有多高——你有多少計算能力？iPhone 的鍵可以更改，還是應該始終相同？了解它是哪種藍牙設備也很有幫助。
另一種方法是使用一次性密鑰。通信可以由藍牙設備發起，藍牙設備儲存了幾個只能使用一次的密鑰——在這種情況下是為了加密會話密鑰。
最後但同樣重要的是，CTR 模式被認為不如 AES 的其他密碼模式安全。就個人而言，我會為你推薦 GCM——因為我喜歡它，而且它還提供經過身份驗證的加密，並且可以輕鬆地進行流水線化。它的塊大小為 128 位。如果您預計會有很多錯誤，OFB 可能對您有用……但這太過分了。如果您按照我的指示進一步澄清您的問題，我可以進一步幫助您。
我強烈建議您使用廣泛接受的密鑰交換技術，例如 STS。如果您好奇，我會在評論中連結到我自己的 STS 規範和實現，這可能具有教育意義。
其中大部分是模糊的。例如，“任何連接的開始”對我來說不夠具體。通信圖在這裡會有所幫助。
也就是說，這裡有一些想法
- 通信是在 iPhone 和藍牙外圍設備之間進行的。在任何連接開始時，iPhone 都會生成一個隨機的公鑰/私鑰對。公鑰將被發送到藍牙設備。
並且設備可以安全地相信這是正確的公鑰？
藍牙設備將生成一個隨機對稱密鑰，使用 iPhone 的公鑰對其進行加密並將其發送回 iPhone。
我目前的理解是可能會發生以下情況：
Device | Adversary | Computer E_p1(randKey) ----> E_p2(randKey2) --->
p1對手的公鑰在哪裡，p2是電腦（或 iPhone）的公鑰。所以現在該設備實際上是在與中間的對手交談，對吧？
現在，所有未來的通信都將使用對稱密鑰進行加密/解密。
該設備用於
randKey與對手和電腦使用者交談randKey2。為藍牙設備生成一次並用於辨識授權使用者的安全密鑰被加密並從 iOS 設備發送到藍牙設備。如果密碼錯誤，則連接被終止。
明智的做法是使用質詢-響應而不是明文密碼。正如我所看到的，攻擊者現在擁有了密碼（並且可以將其轉發到設備上，因此不會失去使用者可見的功能）。
如果正確，iOS 設備現在可以通過加密數據包通信完全訪問藍牙設備。每個新連接都將有一個新的私鑰/公鑰對和一個新的對稱密鑰。
既然您已經概述了密鑰交換，您還應該認為這種“加密數據包通信”也很重要。重播好嗎？亂序消息正常嗎？您如何確保 IV 不被重複使用？鑰匙會“死”嗎？
一個更偏執的問題：你相信藍牙設備上的 RNG 嗎？為什麼？如果它負責密鑰中的所有熵，那麼它最好是偉大的。