這種基於一次性密碼的複制保護方案的安全性分析
想像一下這樣的協議。客戶端和伺服器最初共享秘密 K
$$ 0 $$.
- 當客戶想要聯繫伺服器時，她發送伺服器 K$$ 0 $$和她的身份證。
- 伺服器接受請求，並生成新的隨機 K$$ 1 $$並將其發送給應在下一次通信中使用它的客戶端。
- 同樣，如果客戶端現在想與伺服器進行身份驗證，她發送 K$$ 1 $$. 如果正確，伺服器接受它，並在這裡發送 K$$ 2 $$下次使用等等。
我的第一個問題是：文獻中有這個協議的名稱嗎？（在哪裡研究過這個協議的安全性？）。
我想用它來檢測是否有人複製了我客戶的軟體。
對我來說，這個方案大部分時間都有效：因為如果有人複製客戶端軟體，這意味著原始軟體的副本，會發送說 K
$$ n $$伺服器的密碼，該伺服器將為客戶端 K 生成下一個密碼$$ n+1 $$. 但是這種方式原始客戶端將與伺服器不同步，因為她將使用舊 K$$ n $$進行身份驗證，我們將檢測到這一點 - 並實現我們的目標。 如果中間人只是將客戶端消息轉發到伺服器並且伺服器響應客戶端，那麼我可以在此協議上看到的唯一攻擊。有人可以對這個方案進行安全分析嗎？
這是一個複制保護計劃的動機嗎？
如果是這樣，最明顯的問題是，如果 $ K[n] $ 由伺服器發送但客戶端沒有**收到，則同步失去。
如果中間有代理，就會發生這種情況，這在具有 HTTP（或更具爭議性的 HTTPS）流量的公司網路中通常是這種情況。更新後的值可以傳輸到代理，但不能向下游傳輸到客戶端。在這一點上，應用程序被不可挽回地破壞了。
這個一次性密碼是否通過安全通道傳輸？如果不是，那麼以下問題也適用：
客戶端如何驗證 $ K[n] $ 真的來自您的伺服器而不是其他人？
伺服器如何驗證 $ K[n] $ 提供給它，來自客戶而不是第三方？
如果一次性密碼用於驗證來自有效主機的消息，如何阻止消息在傳輸過程中被修改？
那是行不通的。您甚至已經找到了主要缺陷之一的要點：
如果中間人只是將客戶端消息轉發到伺服器並且伺服器響應客戶端，那麼我可以在此協議上看到的唯一攻擊。
具體來說，您將獲得一個中央代理來轉發消息並儲存 K 的目前值
$$ i $$. 每次有一個客戶端連接時，代理都會替換客戶端的 K$$ j $$由它目前的 K$$ i $$. 您可以嘗試通過在客戶端和伺服器之間建立簽名連接來防止這種攻擊。畢竟，TLS 可以防止中間人攻擊。但這只有在客戶想要避免 MitM 時才有效，而且客戶不會合作。客戶端需要保護它用於簽名的私鑰，或驗證伺服器的公鑰，但在您的場景中，客戶端不受您的控制。
您可以嘗試混淆客戶端執行的加密操作，以便其消息簽名和驗證與它所做的有用工作相關聯，並且無法輕鬆提取密鑰。這種技術對積極主動的、有能力的攻擊者不起作用，但它們可以阻止隨意的攻擊（例如，可能需要幾個月的時間才能有人發布破解）。但是，即使那樣也無濟於事。客戶端需要儲存最後的 K
$$ j $$它在某處收到。如果有人想要製作多個副本，他們所需要的只是讓代理廣播新的 K$$ i $$每次它發出請求，或者讓代理髮送最新的 K$$ i $$讀取時發送給每個客戶。由於客戶端是相同的，一個 K$$ i $$這對一個人來說已經足夠好了，對另一個人來說已經足夠好了，因此您的客戶端和伺服器都無法檢測到這一點。 此外，您提出的協議存在固有的可靠性問題：客戶端和伺服器可能不同步，例如，如果客戶端在下載新的 K 後立即崩潰
$$ i $$. 您必須以某種方式允許這樣做，這為繞過您的協議提供了更多機會。 檢測到軟體是否被複製是不可能的，除非該軟體僅安裝在您完全控制且防篡改的硬體上。如果您無法控制硬體，那麼控制硬體的任何人都可以製作相同的環境（硬體和作業系統）副本並執行相同的客戶端副本。不要在上面浪費時間。