輕量級加密密鑰交換協議

我有一個嵌入式系統通過HTTP向JSON REST服務發佈數據。我目前使用HMAC-SHA1進行驗證，與Amazon AWS一樣。輕量級加密密鑰交換協議

我現在正在探索加密傳輸中的數據的選項。 HTTPS似乎是合乎邏輯的選擇，因爲服務器端需要很少更改。然而，my microcontroller有一個相對較小的閃存（256KB）和RAM（96KB），我可以找到的唯一HTTPS客戶端是商業產品。微控制器通過內置的「AES加密查找表」使加密變得更簡單，但我猜測我需要一種安全的方式來交換密鑰。

我看了一下SSL，它看起來相當複雜。任何其他更輕的選項？

來源

2011-03-09 Tim

SSL的大部分複雜性來自高度模塊化。客戶端可以支持多個「密碼套件」，服務器可以選擇一個。數據可以被壓縮。客戶端可以通過呈現自己的證書並使用相應的私鑰來驗證自己。服務器公鑰作爲X.509證書發送，而X.509證書驗證很複雜。

可以基本被硬編碼的客戶端選擇簡化SSL。例如，你決定你將只支持一個密碼套件，例如TLS_RSA_WITH_AES_128_CBC_SHA256。沒有壓縮。您可以在客戶端硬編碼服務器公鑰，並忽略服務器發送的證書。如果可能的話，使用TLS 1.2，對於以前的協議版本，需要使用單個散列函數（SHA-256）而不是兩個（MD5和SHA-1）（TLS是SSL的標準名稱; TLS 1.0是SSL 3.1）。

我有（專業）來實現，其同時支持AES和3DES一個TLS客戶端，並且執行初步X.509驗證（僅RSA簽名）。完整的代碼適用於21 KB的ROM（對於ARM處理器，用拇指指令編譯的C代碼），並且只需要19 KB RAM，其中16 KB用於輸入緩衝區（輸入記錄的最大尺寸爲假設沒有壓縮，SSL約爲16千字節）。所以SSL 可以對於微控制器來說足夠小。

一旦通過客戶機挑選的參數的先驗選擇簡化SSL，會得到一個協議，該協議是約輕量級因爲它可以得到：剩餘複雜性是本徵的。如果你試圖讓事情變得更簡單，那麼你最終會變得更弱。

至於現有實現方式中，至少PolarSSL旨在嵌入式設備，和下一個開源許可（GPL第二）是可用的。我不知道它有多小可以縮小。還有CyaSSL，它也可以根據GPLv2條款獲得，並聲稱可編譯爲30 KByte代碼（最小選項）。

來源

2011-03-09 14:26:42

剛剛在觀看SSL協商的wireshark蹤跡，我看到你對多個密碼套件的含義。 Chrome廣告多達21個！ – Tim 2011-03-09 14:53:55

@Jim全套密碼套件已經超過100套。 – 2011-03-09 14:59:11

太瘋狂了！我的服務器是否支持絕大多數Chrome瀏覽器，或者至少絕大多數Chrome支持？我猜想我會選擇一個與我的微控制器AES實現最兼容的產品。 – Tim 2011-03-09 22:03:41

SSL使用Diffie-Hellman（DH）密鑰交換。我認爲你可以在代碼中相對容易地實現它（DH）。你需要考慮的唯一問題是，DH本身並不反對中間人（MITM）的攻擊。有幾個選項可以解決這個問題。維基百科的文章提到它們，所以你有一些事情可以從頭開始。

來源

2011-03-09 14:24:02

輕量級加密密鑰交換協議

回答

相關問題