0fc

端到端謹慎的網絡聊天與強密碼學

0FC使您可以使用隔離的聊天室進行安全的瀏覽器組聊天，並具有一些特殊功能：

• 特定聊天室的端到端：服務器不能比DOS攻擊更好
• 服務器被認為是最小信任的區域，所有重要操作發生在客戶端：
  • 用於保護聊天室流量的短暫鍵是在房間所有者的瀏覽器中產生的，並傳播到其餘的
  • 秘密令牌用於訪問聊天室，是在客戶端生成的（儘管部分驗證發生在服務器端）
• 在密鑰共享期間，每個服務消息都受密鑰保護，來自多個一方的隨機數據
• 外向消息被加密並僅發送一次（所有房間成員共享相同的對稱密鑰）
• 一次使用秘密訪問令牌（在密鑰確認後刪除）

0FC作為測試遊樂場的開始，用於某些複雜的themis/webthemis，但變得足夠有趣，可以將其釋放為單獨的代碼斑點。

重要的是：要被認為是真正安全的，0FC應由第三方驗證並正確部署。沒有第三方審核，不得信任加密工具。在此之前（如果有的話），本文檔末尾有一個協議描述，它使您可以查看0FC的內部工作原理並做出自己的判斷。我們自己知道一些與密碼學無關的很少可能的威脅，而是瀏覽器的工作方式（請參閱博客文章的威脅模型部分）。

0FC後端用Python編寫，前端基於WebThemis，因此僅在基於Google Chrome的瀏覽器中起作用（尚未）。

0FC通過Apache 2許可獲得許可。如果您基於此代碼和0FC的協議構建某些內容，我們會很高興；如果您需要任何幫助，請聯繫。

閱讀博客文章，以了解有關0FC和基礎技術的更多信息。

安裝和使用

0FC由兩個組件組成：服務器和客戶端。

0FC服務器

0FC服務器需要：

• Python 3.4
• pip
• 主題（建築和安裝）

首先，您需要安裝Python依賴項：

 pip install -r requirements.txt

這樣做之後，您可以運行服務器：

 python3 server.py

默認情況下，服務器將收聽端口5103。要更改端口add -p <port> ：

 python3 server.py -port 333

0FC客戶端

0FC客戶端已經在 /靜態 /文件夾中編譯。請記住，它的服務器鍵進行了硬編碼；如果您重新生成鑰匙，則需要重建客戶端（請參見下文）。

使用0FC

...很不言而喻。您可以創建新房間，生成令牌並邀請人們加入，或輸入現有的令牌進入房間。

重建0FC客戶端

如果您想自己重新編譯0FC客戶端（PNACL對象），這就是您要做的：

1. 要構建PNACL對象，您需要安裝NACL SDK並使用已安裝SDK文件的路徑創建Enviromant變量PNACL_ROOT 。
2. 克隆0FC存儲庫，帶有GitHub的子模塊：

 git clone https://github.com/cossacklabs/0fc
cd 0fc
git submodules update --init --recursive

3. 構建網絡電視：

 cd webthemis
make

4. 構建0FC PNACL模塊：

 cd ..
make

你完成了！

建築學

0FC由2個經典組件組成：客戶端和服務器。

客戶負責：

• 向用戶顯示UI
• 所有密碼和信任管理功能
• 與繼電器服務器通信

服務器負責：

• 通過HTTP將UI + PEXE（PNACL模塊）提供給客戶
• 運行Websocket繼電器服務，該服務接收消息並將其傳遞給所有人。

通過Websocket鏈接，客戶通過確保Themis對象與服務器進行交談，該對象提供了高級運輸安全性。服務器密鑰被硬編碼為客戶端，因此基於實際服務器密鑰與二進制客戶端的服務器密鑰之間的相關性建立了信任。

在此確保鏈接中，傳輸了證券電路加密的消息。

協議和方案

房間創造

• 房間所有者生成一個鑰匙對[client]
• 房間所有者生成房間鑰匙（將用於加密房間中的消息） [client]
• 房間所有者請求服務器創建房間，接收房間ID以響應[client] + [server]

邀請他人（密鑰共享）

• 房間所有者生成一個隨機的（一次性）邀請令牌[client]
• 房間所有者發送一些帶外頻道的邀請（例如電子郵件），其中包括邀請令牌，他的公鑰和房間ID [client]
• 用戶收到邀請令牌[client]
• 用戶生成一個密鑰對[client]
• 用戶生成隨機加入密鑰[client]
• 用戶通過服務器將安全消息發送給房間所有者，並加入密鑰[client]
• 服務器可以檢查ACL是否有效，並將消息傳遞給房間所有者[server]
• 房間所有者解開加入密鑰[client]
• 房間所有者使用服務器將密封的房間密鑰發送給用戶，使用加入密鑰作為主密鑰，並邀請令牌作為上下文[client]
• 服務器可以檢查ACL是否有效，並將消息傳遞給用戶[server]
• 用戶解開房間密鑰[client]
• 用戶向房間所有者發送確認密封消息。 [client]
• 所有者，檢查用戶確認消息簽署其公共密鑰，並發送到服務器[client] + [server]
• 服務器檢查簽名並考慮將用戶添加到聊天室[server]
• 使用邀請令牌後，它將被房間所有者[server]丟棄

消息交換

• 房間成員交換消息將它們用房間鑰匙密封。服務器只是將加密的消息轉發，而無需訪問其內容。 [server]

密鑰管理

• 每個房間都會生成Keypair [client]
• Keypair存儲在瀏覽器持久存儲[client]中
• 瀏覽器持久存儲使用安全單元格（密封模式），從用戶密碼得出的密鑰，加入聊天時輸入[client]

服務器通信

• 客戶使用Themis Secure Session [server]與服務器通信
• 服務器可信賴的公鑰在客戶端中進行了硬編碼[client]
• 服務器不執行客戶端身份驗證，而是自動信任每個SS客戶端密鑰（如果安全性比無處不在和匿名更重要，這是硬化的第一步） [server]

鑰匙旋轉

• 每100條（可配置的）消息發送和接收，房間所有者會生成新密鑰，使用舊密鑰對其進行加密，並發送特殊消息[client]
• 服務器強制執行此類消息可能僅來自房間所有者[server]

房間編排

• 每個房間都保留一個成員列表，作為公共鑰匙列表（+指示誰是房間所有者） [server]
• 每個房間都有一個房間所有者（最初是房間創建者） [server]
• 房間所有者負責鑰匙旋轉[client]

聊天歷史

• 服務器使客戶自上次出發以來就可以獲取聊天歷史記錄[server]
• 服務器使客戶能夠獲取聊天歷史記錄以來新成員的最後一個密鑰旋轉[server]

想知道更多嗎？

閱讀我們的博客文章，其中具有有關0FC開發和各種安全考慮因素的背景。