限制對稱密鑰的使用
我有一個系統，其中一些客戶端與伺服器通信。每個客戶端都有自己的名稱和角色以及一些其他參數，這些參數在每條消息中將這些資訊發送到伺服器，並且伺服器以某種方式使用這些資訊……
所有通信都使用對稱密鑰加密。我有一個只有我和伺服器知道的主密鑰。客戶端的密鑰通過以下方式從主密鑰派生：
client1_key=hkdf(16, MASTER_KEY, 'client1')客戶端將其加密消息連同其名稱/密鑰 ID 發送到伺服器，因此伺服器可以從主密鑰和客戶端名稱重建客戶端的加密密鑰並解密消息。客戶角色等其他資訊包含在加密部分中，因為我只想在明文通信中顯示最少/絕對必要的資訊。
這裡的一個問題是，使用此方案，客戶端可以聲明，除了它自己的名稱之外，其他不真正屬於的參數是。例如，它可以向伺服器發送它想要的任何角色，而伺服器無法驗證這些參數是否與特定客戶端相關。
我對這個問題的解決方案是在所有受限參數上生成一個 HMAC，並由每個客戶端將其與其他資訊（客戶端名稱和加密消息）一起發送到伺服器。所以每個客戶端都會收到自己的密鑰和限制密鑰使用的隨附 hmac：
key_use_hmac=hmac_sha256(MASTER_KEY, client_name||client_role||another_parameter...)然後在伺服器上，在從解密的消息中提取客戶端參數並與該客戶端沿消息發送的參數進行比較後，重新計算該 hmac，如果它們匹配，則接受該消息，否則拒絕該消息。
客戶端向伺服器發送消息的範例：
name=client1, key_use_hmac=xxxx, encrypted_message=xxxxxxxxxxx只有 name 和 key_use_hmac 以明文形式發送（key_use_hmac 也可以在加密部分發送，但我認為根本沒有必要——我說得對嗎？）。
我想知道我的方案是否足夠健全。
謝謝你！
好的，所以您已經提出了自己的密鑰授權和傳輸加密方案。
密鑰授權方案很好，而且是一個相當標準的解決方案。在網路上使用了類似的方法來確保使用者不會偽造某些 cookie。
每個客戶端的密鑰派生和密鑰管理看起來也不錯，但對於加密，有一個比“普通”加密更好的解決方案：
TLS-PSK。（使用預共享密鑰的傳輸層安全性）
在這種情況下，客戶端可以在握手期間聲明身份，並通過擁有和使用分配的預共享密鑰來確認身份。作為獎勵，TLS 實現將處理所有重放保護和身份驗證問題，並且您只會在握手期間洩漏絕對最少的資訊：客戶端名稱。作為額外的獎勵，您可以將 PSK 與短暫的 Diffie-Hellman (
$$ EC $$DHE) 來獲得前向保密性，並且不會因為
MASTER_KEY在以後的某個時間點洩露您的會話的保密性而受到損害。