基於 RSA 的身份驗證和密鑰協商協議
設備之間的身份驗證和密鑰協商協議應相互證明其身份，並建立共享的隨機秘密 $ R $ 適用於保護以後的通信。
為此，許多設備中的每一個都從證書頒發機構接收證書，綁定它們的身份 $ ID_i $ （包括唯一的序列號和操作特性）到他們唯一的 RSA 公鑰 $ (N_i,E_i) $ . 合法設備 $ ID_i $ 最初假定是唯一擁有 RSA 私鑰的東西 $ (N_i,D_i) $ 對應於其認證的公鑰，並且僅根據協議的規則使用它。
攻擊者的目標是說服合法設備 $ i $ 另一個合法設備 $ j $ 和 $ ID_j $ 在協議期間使用，當它沒有被使用時；或違反保密協議 $ R $ 那 $ i $ 將使用（假設 $ j $ 不會違反它）；或者做那個 $ R $ 與正常執行協議時的情況不同。
協議必須抵制披露 $ R $ 來自較早的執行，以及其他合法設備的私鑰的洩露。通信是不安全的，包括攻擊者更改、重放或創建消息（或與其他合法設備通信，但洩露其私鑰的能力）的能力。
我們可以假設在協議的初步步驟中，兩個參與設備已經清楚地交換了他們所謂的身份和證書；已使用傳統的離線 PKI 驗證證書；並明確同意協議中的主/從角色（從它們各自的靜態確定 $ ID $ ; 或者也許使用具有最高指控的設備 $ ID $ 擔任主角色）。
我們想要一些簡單的、適合在智能卡中實現的東西。我們寧願避免在該協議期間使用分組密碼或 MAC，儘管我們可以假設 RSA 消息/簽名編碼方案中使用的散列。
我正在尋找討論此類協議的文獻（或答案），希望有安全論據。一個理論上的困難是，在每一方，我們都有一個用於相互身份驗證和共享機密性的密鑰 $ R $ .
歐洲法規中規定了一種這樣的協議：EEC 3821/85 經 EC 1360/2002 和 EC 432/2004 修改，附件 1B，附錄 11，CSM_020，第二幅圖，見 PDF 的第 268 頁，從生成挑戰開始. 順便說一句，我對這個協議的起源很感興趣，或者它是否讓人想起其他地方使用的東西；以及它可能具有的其他安全目標。據我所知，它在上述意義上是安全的，但我知道沒有安全分析。我試圖總結該協議，但在我完成符號之前問題的大小翻了一番，所以我現在放棄了。
這與我目前的專業活動無關。
您正在尋找的是基於證書的具有完美前向保密性的經過身份驗證的密鑰協議。
首先，為了解決@Paulo 的評論，TLS/SSL 確實為任何基於 Diffie-Hellman 的套件提供了此功能。但是，它比您需要的要復雜，因為它會生成用於不同目的的幾個不同的共享機密。SSH 和 IPSec 有類似的協議。
具有所需屬性的地標密鑰交換協議稱為站對站協議。我建議在《應用密碼學手冊》（第 12 章，第 519 頁）中討論它（以及整個章節的上下文）。
STS 確實需要您指定要避免的加密功能。沒有加密功能的現代密鑰交換是MQV及其變體。由於您還需要嚴格的安全證明，因此關於 MQV 及其變體的安全性的文章可能比任何其他協議都多（儘管歷史有些骯髒）。您的缺點是它要求公鑰（在證書中）是基於離散日誌的而不是 RSA（STS 可以使用 RSA 公鑰，因為長期機密僅用於簽名）。它也可能受到專利保護。
總而言之，我沒有一個完美的協議，既可以與 RSA 一起使用，又可以避免使用加密或 MAC，但是研究這兩個協議應該可以讓您在尋找可以使用的東西上搶先一步。