Protocol-Design

消息安全和程序複製檢測

  • December 7, 2015

想像一下,我有客戶端和伺服器在不同的機器上執行,每一個都是單獨的軟體。我想確保:

  1. 至少來自客戶端的消息的真實性、完整性和機密性。
  2. 而且我希望能夠檢測是否有人在不同的機器上複製了我的客戶端軟體並試圖在那裡提出請求

現在解決第 1 項。我將在客戶端和伺服器上使用 SSL (順便說一句,是否需要相互身份驗證?)身份驗證。這解決了1,對嗎?

為了解決 2,我打算將以下協議與 SSL 一起使用:

  • 客戶端使用 SSL 連接到伺服器後,伺服器會向客戶端發送一些隨機數。當然,每個客戶端都可以有一些 ID。
  • 客戶端必須在與伺服器的下一次迭代中使用此數字。互動成功後,伺服器向客戶端發送不同的隨機數,客戶端在下次與伺服器互動時必須使用該隨機數,以此類推。

現在,想法是如果有人複製我的客戶端軟體,她的程序副本將使用伺服器提供的隨機數 - 但這會使我的原始客戶端與伺服器不同步(因為她的隨機數已被使用) -我將能夠檢測到這一點。這意味著我的目標已經實現,正如我最初列出的那樣。這是否實現了我在列表中的第 2 項?如果沒有改進?

根據定義傳統密碼學(包括公鑰密碼學)的要求不能滿足所述目標;最重要的是,除了密鑰之外,所有使用的方法都是公開的,並且通信渠道可以被竊聽和更改(就像在被盜電腦或完全受其流氓使用者控制的電腦上經常發生的那樣)。

目前的問題仍不清楚客戶端電腦是否包含一些初始密鑰/私鑰(和證書,如果該密鑰最初不為伺服器所知)。我想他們沒有。如果他們這樣做了,並且可以被信任,並且由受信任的方操作,那麼問題就變得微不足道了(另請參閱此答案的最後一段)。

目標 1

如果軟體是公開的,並且客戶端沒有初始機密,那麼從密碼學的角度來看,SSL/TLS(或密碼學)可以達到的唯一目標是向伺服器發送消息的機密性,以及**來自的消息的真實性+完整性伺服器。

對於其他方向:我們面臨的問題是,如果沒有與已確定實體相關聯的初始秘密,我們就無法製作與已確定實體相關聯的秘密,因此無法加密或確定來自已確定實體的來源,在這些事情的意義上有密碼學;可以獲得的最好的:

  1. 需要對軟體進行逆向工程(並且在某種程度上很難),以損害來自伺服器的消息的機密性,而該軟體不會以其他方式清楚地輸出,或損害由生成的消息的真實性和完整性軟體本身(而不是被接受為輸入);換句話說,該軟體被認為足夠晦澀,可以保存一些秘密,使其成為可加密辨識的實體。
  2. 在受信任的電腦上(因此不包括被篡改或完全控制的流氓使用者),在首先執行執行適當協議(可能是密鑰交換協議或證書請求協議)的軟體的未修改副本之後,這台電腦/software 可以保存秘密並成為確定的實體,可以對哪些消息進行身份驗證+完整性檢查,並且可以接收除伺服器之外的其他電腦無法解密的機密消息。請注意,伺服器實際上無法區分這種期望的情況,以及秘密最終在許多流氓使用者之間共享的不同現實(例如,該軟體可以在單個VM中執行,並且該虛擬機的使用一次允許多個流氓使用者使用,包括該虛擬機在他們的電腦上執行,並且由於VPN,伺服器只能看到一個IP ;另請參閱此答案的最後一段)。

目標 2

如果該軟體是公開的,並且您假設原始機器由對手(包括遠端)操作(或 pwned),那麼從密碼學的角度來看,沒有辦法檢測到該軟體的副本正在執行。可以獲得的最好的:

  1. 它被檢測/阻止同時在兩台機器上執行未經修改的軟體副本。
  2. 它被檢測/防止在兩台機器上交替執行未修改的軟體副本,這兩個機器不是相互合作和相互通信。
  3. 需要對軟體進行逆向工程(並且在某種程度上很難),以便在伺服器未知的情況下執行軟體的修改副本,該副本在很大程度上等同於原始程序,除了伺服器執行的功能和本地軟體不能; 此外,對於未觀察到在經過檢測的授權軟體上至少執行一次的功能,所需的逆向工程可以通過加密方式(通過加密相應的程式碼)變得不可能。

問題中的方法似乎能夠滿足目標2的1和2。但是

  • 細節決定成敗; 特別是,在“伺服器將向客戶端發送一些隨機數”步驟中的消息失去的情況下,系統應該可靠地工作,這可能是偶然發生的,或者是由軟體外部的許多方式引起的(如問題 #1 中的這個對相關問題的回答)。因此,伺服器有時必須在與客戶端的下一次互動中容忍兩個不同的值。很難讓其可靠地工作並且不會受到欺詐,從而允許同時使用兩個副本,尤其是通過控制兩台電腦的對手。
  • 在現實生活中,存在軟體破解,因此假設軟體未經修改是不現實的。
  • Pwned 機器可以相互合作和交流,而它們各自的誠實使用者卻不知道。
  • 他們完全控制的任何機器的流氓使用者都可以使這些機器合作和交流,如果被抓到,甚至可以假裝被攻擊作為藉口。

如果**“忽略軟體破解等”**對此進行了一些廣泛的定義(這可以匹配一些現實生活中的情況,即沒有有能力和堅定的對手可以訪問軟體的工作實例);並且,對於雙向的目標 1,每個客戶端唯一的初始秘密,並且可用於客戶端的身份驗證(例如,因為它是公鑰系統的私鑰,並且對應的公鑰是經過認證的,並且私鑰在TPM等受信任的硬體中);並按照解釋調整問題中的協議;那麼是的,問題中概述的協議可以實現目標 1 和 2,至少在我所說的範圍內。

從來沒有寫過hello world的人!任何編譯語言的程序都可以在免費的Virtualbox軟體中安裝軟體,以規避軟體複製保護。即使軟體只允許在具有有效 SSL 證書和匹配私鑰的機器上使用(這將是非常不尋常的,並且對普通使用者來說不方便),這也是適用的。問題中的技術不會阻止這些人將該虛擬機放在他們可以移動或借出的 USB 驅動器上,或者“放入雲中”並通過一些記憶體使其非常可用。問題中的技術將防止執行該虛擬機的多個實例,從而阻止原始所有者允許多個實例,因為擔心無法使用該軟體。從這個意義上說,該技術實際上是有用的。然而,這不是關於 CSE 主題的加密貨幣;這是默默無聞的安全,但事實並非如此。

引用自:https://crypto.stackexchange.com/questions/31081