Authentication

TEA 是否適合加密/驗證許多短消息?

  • October 14, 2020

我知道 TEA 有其弱點,但很容易實施。我的問題是它是否適合我的案例:使用加密的主要原因不是保密,而是身份驗證和防止干擾。

  • 我有一些(最多 20-30 個)GPS 跟踪器,它們通過無線電將它們的位置間隔發送到基站。
  • 每條消息都包含一個跟踪器 ID、一個時間戳、位置和一個校驗和,因此最多 16 個字節,但格式固定。
  • 每條消息都將與前一條消息相似,因為時間增量將是恆定的,並且在兩個後續消息之間位置不會有太大變化。
  • 時間框架大約是三個小時,在此期間每台設備可能發送大約 800 條消息。所以總共大約有 20k 條消息。
  • 系統的程式碼可能是公開的(因此通過默默無聞的安全性肯定行不通)

我想避免發生任何人發送被誤認為是真實職位的虛假資訊;解碼消息內容不是問題,因為任何人都可以觀察到跟踪器的移動,如果他們願意的話。因此,如果破解密鑰並啟用發送虛假消息需要三個多小時,那將不是問題,因為這意味著使用單個密鑰的視窗將結束。

我想我真正需要知道的是:

  1. TEA(或 XTEA,或 XXTEA)是否完全適合此案例?如果是這樣,香草還是 X/XX?還是有另一種更適合的算法?例如,只是一個雜湊校驗和?
  2. 有沒有其他方法可以提高安全性(例如,為每個跟踪器使用不同的密鑰,隨機改變消息的格式(位置優先與時間戳優先),壓縮消息(僅儲存與先前位置的差異,例如,刪除一些冗餘))

我的主要設計目標是合理的安全性(這是競技運動,而不是秘密導彈計劃)、使用和實現的簡單性(我是開發人員,而不是密碼學專家)和低計算成本(這將在 ESP32 微控制器上執行) .

我對此有一些基本的想法,但希望得到一些專家的建議!

更新:由於在其中一個答案中提出了這個問題:跟踪器將在加電時在附近進行初始化,並且基站可以通過低功耗藍牙向每個跟踪器傳輸“秘密”密鑰。我確實意識到藍牙並不是真正安全的,但鑑於距離很近,我認為這風險可以忽略不計。

我想避免發生的是任何人發送虛假資訊

最簡單的選擇是

  • 一個密鑰 $ K $ 在對手(“任何人”)無法到達的跟踪器和基站中。這是困難的部分,最初的問題對此很短。雖然BLE 配對並不完美,但至少這是一個合理的計劃。
  • 使用該密鑰製作和檢查的消息的消息驗證碼。該 MAC 將附加到消息中,未加密發送。

TEA(或 XTEA,或 XXTEA)是否完全適合此案例?

的,如果您可以設法擁有一個隨機的 16 字節密鑰,則可以使用 TEA 製作消息驗證碼 $ K $ 僅由跟踪器和基地共享。對於固定的 16 字節消息,即兩個 8 字節塊 $ M_0\mathbin|M_1 $ , 和 $ \text{TEA}_K(\text{TEA}_K(M_0)\oplus M_1) $ 根據CBC-MAC結構,將是一個精細的 8 字節 MAC (如果消息大小是可變的,則需要適當的填充;如果可以從第一個塊中確定該數量,則可變數量的消息塊仍然是安全的)。

香草還是 X/XX?

在上下文中任何都是安全的,但我會使用香草,因為它是研究得最好且最簡單的。XTEA 和 XXTEA 都沒有達到他們更雄心勃勃的設計目標,請看這個

是否有另一種更適合的算法?

另一個推薦的消息驗證碼是HMAC -SHA-256。如果您手頭有 SHA-256,它會更適合,並且被廣泛認為是安全的。

如果出於某種原因我們想要加密(儘管沒有必要滿足規定的安全目標),我們想要經過身份驗證的加密(如另一個答案中所設想的)。這可以建立在頂級 TEA 之上,但會增加相當大的複雜性。特別是,這可能需要兩個密鑰(一個用於加密,另一個用於身份驗證,至少在內部);並且存在確保唯一(如果不是不可預測的)IV的問題。

還有其他方法可以提高安全性嗎?

如果對手需要破解多個跟踪器而不是一個來執行他們的邪惡計劃,則為每個跟踪器使用不同的密鑰很有用。基站需要根據tracker ID選擇密鑰(從消息中找到,至少在這個段不能加密)。

對於好的 MAC,是否有許多非常相似的消息無關緊要。因此,問題中的其他想法增加了複雜性,並且充其量只是很少的安全性,我會說從安全形度來看它們的淨餘額是負面的。

基站壓制(或標記為可疑)時間戳與目前 GPS 時間不一致的消息(或早或晚超過一些容限,分別很小和很小)是有用的。這可以防止重播(並且比將時間戳與來自同一跟踪器的早期經過身份驗證的消息進行比較更容易免受臨時故障的影響)。

特別是與每個跟踪器的密鑰結合使用時,基站通過檢查自較早位置(從來自該跟踪器的經過驗證的消息獲得)以來的距離是否在物理上是可能的(例如,距離小於時間戳的乘積)來驗證來自每個跟踪器的數據非常有用與一些最大速度的差異)。

在設置階段添加Diffie-Hellman 密鑰交換將使初始 BLE 連接的被動竊聽無法揭示密鑰(即使該連接在某種程度上沒有使用 BLE 配對中眾多選項中的最佳選項)。它不會防御所有主動攻擊,但這些攻擊更難攜帶,尤其是遠距離攻擊。

引用自:https://crypto.stackexchange.com/questions/85540