從 arduino 等小型設備將兩個浮點數發送到 Internet 上的伺服器的最佳方法是什麼？
我正在考慮將一些敏感數據（溫度）從 arduino（AVR 8 位處理器）發送到網際網路上的伺服器。
但我想確保夏娃不可能找到溫度。
我知道解決這個問題的唯一方法是在 arduino 和 Eve 不知道的伺服器之間共享一個秘密。但是，默默無聞的安全性與伺服器和 arduino 共享的編譯時常量之間的界限在哪裡？（由於性能和（預期的）實現問題，我排除了非對稱加密）。
因此，假設他們可以使用密鑰加密數據，我仍然有一種已知的明文問題，因為 Eve 知道（從閱讀原始碼）我在可預測的範圍內發送 2 個浮點數（-20C..50C）。我能想到的唯一解決方案是將 2 個浮點數交錯在一個隨機浮點數組和一個初始（隨機）字節中，以指示所使用的交錯類型。雖然這聽起來可以增加安全性，但我想知道它是否確實如此。
所以也許回顧一下：將兩個溫度測量值發送到網際網路上的伺服器的最佳方案是什麼？
附言。目前我並不擔心身份驗證，但如果需要我可以添加 H/CMAC？
你必須準確定義夏娃能做什麼和不能做什麼。例如，Eve 是否偶爾物理訪問基於 Arduino 的設備？如果是，那麼她可以（至少在概念上）抓取設備，“打開”它，提取共享秘密，然後用這裡自己的設備替換設備，它做同樣的工作，除了它還發送數據的副本到 Eve 控制的另一台伺服器。可以說，她也可以在你的旁邊添加她自己的測量設備，以達到同樣的效果。這將是一個相當困難的安全模型。
如果 Eve 沒有偶爾對設備的物理訪問，那麼“共享密鑰”模型就可以了。你還是要小心這個秘密；例如，如果您部署多個基於 Arduino 的設備，讓它們中的每一個使用自己的密鑰，與其他設備中的密鑰無關。
至於加密部分：
- 您確實需要完整性檢查，即Message Authentication Code。否則，例如，Eve 可以攔截消息並用舊消息替換它們。Eve 不會直接學習數據，但這可能對您的系統有害。
- 您需要對每條消息進行一些隨機性，或者設備上的一些記憶體，以避免出現問題。沒有任何一個，同一對溫度值將產生相同的加密消息，這對 Eve 是可見的。實際上，如果你只使用隨機性而不使用記憶，Eve 可以隨意重新排序消息，這也可能是一個問題。我所說的“記憶體”是指設備必須能夠儲存一個值並對其進行更改，並且這樣儲存才能抵抗重新啟動。
這是一個確保安全的特定方案：加密一對溫度值，將它們編碼成一個 128 位的字，其中包含按順序：第一個溫度（超過 24 位），第二個溫度（24 位），一個欄位僅包含零（48 位）和計數器（32 位）。然後使用AES將其加密為一個塊（密鑰是設備和伺服器之間共享的秘密）。這會產生一個 128 位的值，您可以將其發送到伺服器。必須小心管理計數器：
- 計數器必須從 0 開始。對於每條消息，計數器必須遞增。即使在暫時斷電的情況下，也不能將計數器“重置”為先前的值。
- 伺服器必須在解密時驗證包含零的欄位確實只包含零。這就是MAC的作用。
- 伺服器必須儲存來自設備的最後接收消息的計數器值。僅當新消息的計數器值大於儲存的計數器值時才接受新消息。（潛在地，伺服器可以執行更嚴格的規則，例如拒絕將計數器值增加超過 100。）
在這些條件下，該設備可以處理大約 40 億條消息。即使它每秒發送一條消息，這仍然需要 120 年才能用完計數器值。
安全性來自 AES 與 128 位塊空間上的隨機排列的不可區分性。它不適用於具有較小塊的塊密碼，例如 DES（或 TripleDES）。另外，作為 MAC 的“零場”不能太短；Eve 可以發送帶有隨機垃圾的消息，而 48 位欄位意味著看到這樣的消息被伺服器接受為真實的風險就在附近 $ 2^{-48} $ – 由於每條消息的長度為 16 字節，因此平均需要 $ 2^{52} $ 字節（4000 TB）讓 Eve 成功。4000 TB，這是巨大的，但並非不可能巨大。如果將此欄位縮短為 30 個字節，那麼這些欄位將變為 16 GB，這是非常可行的。