OMP3334專案端到端加密聊天
web應用程式2023/2024年第2學期如今，web服務是最重要的使用者的常見應用程式形式暴露於。Web瀏覽器成為計算機上的流行應用程式使使用者能夠訪問這些web服務。確保web服務的安全是對網際網路至關重要。此外，隱私的一個重要特徵現代。您的工作是實現端到端加密聊天web應用程式以及保護網站的各個方面。概述目標
1.調整一個基本的聊天網路應用程式，使其成為一個安全的E2EE聊天網路應用
2.符合NIST特別出版物800-63B“數字”中的一些要求身份指南——身份驗證和生命週期管理”，適用於美國聯邦機構（這也是其他型別系統的參考）
3.實現基於密碼和OTP（或FIDO2）的安全MFA機制
4.加密兩個使用者之間的通訊，使伺服器不知道訊息的內容（E2E加密）5.透過配置現代TLS部署來保護傳輸中的通訊6.打包您的網路應用程式的docker影像要求（身份驗證）1.來自NIST特別出版物800-63B：
符合以下各節的所有“應”和“宜”要求2.使用以下驗證器：使用者選擇的記憶密碼（即密碼/密碼短語）和單因素OTP裝置（例如Google Authenticator）或單因素加密裝置（例如Yubikey）（如果您有）和查詢機密（恢復金鑰）符合§5.1和§4.2.2中的相關要求
§5.1.1.2：“記憶中的秘密應使用合適的單向金鑰進行加鹽和雜湊處理推導函式”有關適當的功能，請參閱我們的密碼安全講座記憶秘密驗證器（§5.1.1.2）選擇“從以前的違規公司獲得的密碼”，並參考以供語料庫檢查自動遵守§5.2.8和§5.2.9要求（身份驗證）.來自NIST特別出版物800-63B：
3.§5.2.2：實施速率限制機制和基於影像的CAPTCHA4.在上實現新的帳戶註冊和繫結驗證器（OTP/Yubikey和恢復金鑰）同時可選：提供一種在帳戶註冊後更改驗證器的方法5.§7.1：實施適當的會話約束要求6.例外情況：OTP驗證器——尤其是基於軟體的OTP生成器——應該勸阻和不得促進將金鑰克隆到多個裝置上。谷歌驗證器和相關應用程式正常要求（E2EE聊天）2.使用者登入後，以某種方式保護兩個使用者之間的聊天訊息，使伺服器無法解密訊息1.使用ECDH金鑰交換協議在兩個使用者之間建立共享秘密利用WebCrypto API，請參閱演示金鑰交換過程中交換的資訊可以透過伺服器傳送信任伺服器不會修改金鑰交換的訊息選擇P-384作為基礎曲線2.從共享秘密中匯出兩個256位AES-GCM加密金鑰和兩個256位元MAC金鑰使用HKDF-SHA256一個金鑰用於在user1到user2之間加密，另一個金鑰從user2到user1再次使用WebCrypto API，請參閱https://developer.mozilla.org/enUS/docs/Web/API/HkdfParams鹽應該是唯一的，這樣將來的另一個金鑰派生會產生不同的金鑰，使用例如從1開始的計數器info引數應表示當前上下文（例如，的“CHAT_KEY_USER1to2”使用者1的金鑰user2，“CHAT_MAC_USER1to2”表示user1的MAC金鑰user2）要求（E2EE聊天）2.使用者登入後，以某種方式保護兩個使用者之間的聊天訊息，使伺服器無法解密訊息3.訊息將在GCM模式下使用AES加密96位IV是表示使用相同金鑰加密的訊息數量的計數器注意：GCM不需要不可預測的IVs，而是需要獨特的IVs將IV和密文一起傳送給收件人作為接受者，驗證靜脈注射>
四、
1以防止重放攻擊使用派生的MAC金鑰使用HMAC-SHA256保護IV，以防止攻擊者選擇IVs相關資料應反映當前上下文（例如，“CHAT_MSG_USER1to2”）身份驗證標籤應為128位4.將所有關鍵材料儲存在瀏覽器的HTML5本地儲存中，以便在瀏覽器之後檢索重新開啟5.顯示正在交換的先前訊息的歷史記錄+新訊息如果本地儲存已被清除，則無法解密以前的訊息，顯示警告要求（E2EE聊天）
2.使用者登入後，以某種方式保護兩個使用者之間的聊天訊息，使伺服器無法解密訊息6.當使用者點選聊天中的“重新整理”按鈕（而不是瀏覽器重新整理按鈕），使用新的鹽要求更改的參與者應透過特殊資訊通知另一方由已使用的最後一個IV組成，字串“change”，完全受保護舊MAC金鑰與新MAC金鑰訊息上的兩個不同MAC另一方應在處理訊息之前驗證舊MAC，然後匯出新金鑰，並在接受新金鑰之前再次驗證新MAC雙方應在聊天記錄中顯示一條訊息“金鑰已更改”當瀏覽器重新開啟時，應保留舊金鑰以解密舊訊息應根據前面的值確定要用於給定訊息的金鑰集在金鑰交換期間傳送（即，跟蹤使用者公鑰）超過一分鐘的金鑰交換訊息不應被視為新金鑰要參與的交換要求（E2EE聊天）2.使用者登入後，以某種方式保護兩個使用者之間的聊天訊息，使伺服器無法解代 寫COMP3334專案端到端加密聊天密訊息7.當本地儲存被清除時，或者當給定收件人沒有共享機密時傳送方應使用特殊訊息啟動ECDH金鑰交換，接收方應即使之前已經建立了共享秘密，也要參與金鑰交換8.聊天訊息應使用UTF-8編碼，使用者之間的網路訊息應為使用您自己的模式（例如，｛“type”：“ECDH”、“key”：“…”｝、｛“type”：“msg”，“密文”：“…”，“IV”：“.”，“MAC”：“..”}）9.使用console.log（）記錄所有加密操作（包括金鑰、IV、明文等）從視覺上看，IVs不可重複使用，按鍵在需要時會發生變化（見下一頁要求）等。10.聊天應用程式應防止跨站點請求偽造（CSRF）、跨站點指令碼（XSS）和SQL隱碼攻擊要求（TLS）3.通訊應在傳輸過程中使用TLS進行加密，配置如下：重新使用Mozilla的nginx“現代”配置，並根據需要進行更改：https://ssl-config.mozilla.org/1.僅限TLS版本1.32.x25519僅橢圓曲線組3.僅TLS_CHACHA20_POLY1305_SHA256密碼套件4.沒有OCSP裝訂（因為您將使用自簽名的CA證書）
5.HSTS為期一週6.TLS證書要求：1.X.509版本32.P-384上的ECDSA公鑰3.SHA384作為簽名的雜湊演算法4.CA標誌（關鍵）：false5.金鑰使用（關鍵）=數字簽名6.擴充套件金鑰使用=伺服器身份驗證7.包括主題金鑰識別符號和授權金鑰識別符號8.有效期=90天要求（TLS）3.通訊應在傳輸過程中使用TLS進行加密，配置如下：7.網站應位於https://group-[您的組號].comp3334.xavier2dc.fr:8443/第10組將在Group-10.comp3334.xavier2dc.fr8.所有子域*.comp3334.xavier2dc.fr將重定向到127.0.0.1您可以有效地使用“group-X.comp3334.xavier2dc.fr”而不是“localhost”如果您沒有在localhost上託管docker容器，在主機檔案中新增手動條目Linux:/etc/主機Windows:C:\Windows\System32\drivers\etc\hosts9.從給定的CA證書和私鑰頒發證書使用與您的組對應的域名域名應同時顯示為通用名稱和使用者備選名稱10.CA證書的域限制為comp3334.xavier2dc.fr的子域，意思是你可以在你的計算機上安全地信任它（沒有人可以為其他人生成有效的證書域）簡單聊天演示1.在包含dockercompose.yaml檔案的資料夾中使用以下行部署docker容器：$sudo docker compose up-d2.到目前為止，聊天應用程式在8080埠上透過純HTTP工作，訪問地址：http://group-0.comp3334.xavier2dc.fr:80803.開啟瀏覽器的新私人視窗，然後再次訪問網站1.鉻：2.Firefox：
4.在第一個視窗中以Alice（密碼：password123）的身份登入5.以Bob（密碼：password456）的身份登入第二個（私人）視窗6.從Alice聊天中選擇Bob作為聯絡人，從Bob聊天中選擇Alice作為聯絡人7.互相傳送訊息！8.當修改伺服器端（app.py）或客戶端（login.html，chat.html）時，只需重新啟動docker容器，則不需要重新構建容器：$sudo docker restart[you container name]-webapp-1評估領域1.對您的解決方案和設計的解釋[50%]提供實施的功能/要求列表描述您的解決方案是如何工作的，特別是解釋使用者密碼是如何儲存、驗證、使用哪些庫、如何派生關鍵材質、如何你儲存它們嗎，它們的大小，你如何生成域